* 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: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
* 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
* [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: 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
* Re: First web interface and service API draft
From: El Draper @ 2005-04-22 12:37 UTC (permalink / raw)
To: Christian Meder; +Cc: git
In-Reply-To: <1114166517.3233.4.camel@localhost>
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.
Regards,
-= El =-
^ permalink raw reply
* Re: First web interface and service API draft
From: Jon Seymour @ 2005-04-22 12:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Christian Meder, git
In-Reply-To: <20050422121059.GB7173@pasky.ji.cz>
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.
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
>
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
^ permalink raw reply
* Re: First web interface and service API draft
From: Petr Baudis @ 2005-04-22 12:10 UTC (permalink / raw)
To: Jon Seymour; +Cc: Christian Meder, git
In-Reply-To: <2cfc4032050422043419b578cd@mail.gmail.com>
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
^ permalink raw reply
* Re: First web interface and service API draft
From: Petr Baudis @ 2005-04-22 12:10 UTC (permalink / raw)
To: Christian Meder; +Cc: git
In-Reply-To: <1114166517.3233.4.camel@localhost>
Dear diary, on Fri, Apr 22, 2005 at 12:41:56PM CEST, I got a letter
where Christian Meder <chris@absolutegiganten.org> told me that...
> Hi,
Hi,
> /<project>
>
> Ok. The URI should start by stating the project name
> e.g. /linux-2.6. This does bloat the URI slightly but I don't think
> that we want to have one root namespace per git archive in the long
> run. Additionally you can always put rewriting or redirecting rules at
> the root level for additional convenience when there's an obvious
> default project.
>
> Should provide some meta data, stats, etc. if available.
I don't think this makes much sense. I think you should just apply -p1
to all the directories, and define that there should be some / page
which should contain some metadata regarding the repository you are
accessing (probably branches, tags, and such).
> -------
> /<project>/blob/<blob-sha1>
> /<project>/commit/<commit-sha1>
>
> These are the easy ones: the web interface should be able to spit out
> the plain text data of a blob and a commit at these URIs. Users would
> be probably scripts and other downloads.
> Open questions:
> * Blob data should be probably binary ?
What do you mean by binary?
> * Should it be commit or changeset ? Linus seems to have changed
> nomenclature in the REAME
We call it commit everywhere but in the README. :-)
The "changeset" name is bad anyway. It is a commit of a complete tree
state, diff against one of its parent commits is the set of changes.
> -------
> /<project>/tree/<tree-sha1>
>
> Tree objects are served in binary form. Primary audience are scripts,
> etc. Human beings will probably get a heart attack when they
> accidentally visit this URI.
Binary form is unusable for scripts.
Anything wrong with putting ls-tree output there?
We should also have /gitobj/<sha1> for fetching the raw git objects.
> -------
> /<project>/blob/<blob-sha1>.html
> /<project>/commit/<commit-sha1>.html
> /<project>/tree/<tree-sha1>.html
>
> A HTML version of blob, commit and tree fully linked aimed at human
> beings.
How can I imagine an "HTML version of blob"?
> -------
> /<project>/tree/<tree-sha1>/diff/<ancestor-tree-sha1>/html
>
> Non recursive HTML view of the objects which are contained in the diff
> fully linked with the individual HTML views.
Why not .html?
> -------
> /<project>/changelog/<time-spec>
I'd personally prefer /log/, but whatever.
For consistency, I'd stay with the plaintext output by default, .html if
requested.
And I think abusing directories for this is bad. Query string seems much
more appropriate, since this is something that changes dynamically a
lot, not a permanent resource identifier.
OTOH, I'd use
/log/<commit>
to specify what commit to start at. It just does not make sense
otherwise, you would not know where to start.
I think the <commit> should follow the same or similar rules as Cogito
id decoding. E.g. to get latest Linus' changelog, you'd do
/log/linus
> -------
> /<project>/changelog/<time-spec>/search/<regexp>
>
> HTML changelog for the given <time-spec> filtered by the <regexp>.
>
> * again plain version needed ?
>
> ------
> /<project>/changelog/<time-spec>/search/author/<regexp>
> /<project>/changelog/<time-spec>/search/committer/<regexp>
> /<project>/changelog/<time-spec>/search/signedoffby/<regexp>
>
> convenience wrappers for generic search restricted to these fields.
Same here. just ?author=...&committer=...&signedoffby=... etc. You can
even combine several criteria.
> ------
>
> open questions:
> * how to generate and publish additional merge information ?
I don't understand....
> * how to generate and publish tree and blob history information ? This
> is probably expensive with git.
...this either.
> * how to represent branches ? should we code up the branches in the
> project id like linux-2.6-mm or whatever ?
See above.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: First web interface and service API draft
From: Jon Seymour @ 2005-04-22 11:34 UTC (permalink / raw)
To: Christian Meder; +Cc: git
In-Reply-To: <1114166517.3233.4.camel@localhost>
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.
jon.
^ permalink raw reply
* First web interface and service API draft
From: Christian Meder @ 2005-04-22 10:41 UTC (permalink / raw)
To: git
Hi,
me again after a couple of hours of sleep ;-)
This probably gets a bit longer so if you are not interested in a web
service api or the web interface now is your chance to get off the
train.
I'm probably making a complete git of myself but that's not uncalled
for in this contxt ;-)
For those that are still with me let me start by iterating again that
I _do_ care for URIs as the primary API for web service
applications _and_ humans. I probably don't have to tell Linux people
anything about the importance to get the API right ;-)
As it's fairly early in the web service interface cycle I like to change
things around a little bit and starting to get the API straight.
The following considerations should be pretty implementation agnostic
and not specific to wit. The interface should be flexible enough to be
used as a kind of web command line.
-------
/<project>
Ok. The URI should start by stating the project name
e.g. /linux-2.6. This does bloat the URI slightly but I don't think
that we want to have one root namespace per git archive in the long
run. Additionally you can always put rewriting or redirecting rules at
the root level for additional convenience when there's an obvious
default project.
Should provide some meta data, stats, etc. if available.
-------
/<project>/blob/<blob-sha1>
/<project>/commit/<commit-sha1>
These are the easy ones: the web interface should be able to spit out
the plain text data of a blob and a commit at these URIs. Users would
be probably scripts and other downloads.
Open questions:
* Blob data should be probably binary ?
* Should it be commit or changeset ? Linus seems to have changed
nomenclature in the REAME
* If we serve the pristine commit objects we will put the email
addresses in plain sight. If we remove or change the email addresses
it's not the original commit object anymore. Thoughts ?
-------
/<project>/tree/<tree-sha1>
Tree objects are served in binary form. Primary audience are scripts,
etc. Human beings will probably get a heart attack when they
accidentally visit this URI.
-------
/<project>/blob/<blob-sha1>.html
/<project>/commit/<commit-sha1>.html
/<project>/tree/<tree-sha1>.html
A HTML version of blob, commit and tree fully linked aimed at human
beings.
-------
/<project>/tree/<tree-sha1>.tar.bz2
/<project>/tree/<tree-sha1>.tar.gz
/<project>/commit/<commit-sha1>.tar.bz2
/<project>/commit/<commit-sha1>.tar.gz
Tarballs of the specified commits or trees. Note that these can be
individual subtrees too.
-------
/<project>/tree/<tree-sha1>/diff/<ancestor-tree-sha1>
Unified plain text recursive diff of the given trees. I guess the
user could specify any two tree ids but the relevance of the results
would vary greatly ;-)
* Possibly a DOS issue
* does something like /<project>/tree/<tree-sha1>/diff/ make sense
producing a full diff from scratch ?
-------
/<project>/tree/<tree-sha1>/diff/<ancestor-tree-sha1>/html
Non recursive HTML view of the objects which are contained in the diff
fully linked with the individual HTML views.
-------
/<project>/blob/<blob-sha1>/diff/<ancestor-sha1>
Unified plain text diff of the given blobs.
* again /<project>/blob/<blob-sha1>/diff/ sensible ?
-------
/<project>/blob/<blob-sha1>/diff/<ancestor-sha1>/html
HTML view (probably colorized) view of a single blob diff.
-------
/<project>/changelog/<time-spec>
HTML changelog for the given <time-spec>. I think valid values for
timespec should be number of days <nnn>d, number of entries <nnn> and
the keyword 'all'.
* perhaps additionally number of hours <nnn>h, number of months
<nnn>m, number of years <nnn>y. Combinations shouldn't be allowed
* time ranges are probably overkill
* is a plain text version needed /<project>/changelog/<time-spec/plain?
-------
/<project>/changelog/<time-spec>/search/<regexp>
HTML changelog for the given <time-spec> filtered by the <regexp>.
* again plain version needed ?
------
/<project>/changelog/<time-spec>/search/author/<regexp>
/<project>/changelog/<time-spec>/search/committer/<regexp>
/<project>/changelog/<time-spec>/search/signedoffby/<regexp>
convenience wrappers for generic search restricted to these fields.
------
open questions:
* how to generate and publish additional merge information ?
* how to generate and publish tree and blob history information ? This
is probably expensive with git.
* how to represent branches ? should we code up the branches in the
project id like linux-2.6-mm or whatever ?
Comments ? Ideas ? Other feedback ?
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: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Petr Baudis @ 2005-04-22 10:37 UTC (permalink / raw)
To: Barry K. Nathan; +Cc: git
In-Reply-To: <20050422072437.GC8467@ip68-225-251-162.oc.oc.cox.net>
Dear diary, on Fri, Apr 22, 2005 at 09:24:37AM CEST, I got a letter
where "Barry K. Nathan" <barryn@pobox.com> told me that...
> On Fri, Apr 22, 2005 at 12:16:26AM -0700, Barry K. Nathan wrote:
> > With git-pasky 0.6.3, "git log" is unusable on my Mandrake 10.1 system.
> > Basically I get a neverending flood of these until I press 'q' to quit
> > less:
> [snip sed segmentation faults which happen with 0.6.3 but not 0.6.2]
> > I'm not sure if I have time tonight (or tomorrow) to troubleshoot this
> > further, but I'll see if I can.
>
> I had sed-4.1.1-2mdk. I downloaded sed-4.1.4-2mdk (from Mandriva 2005
> Limited Edition) and updated to that, and the problem went away.
>
> FWIW this is the second package I've had to update to the Mandriva 2005
> LE level (the first was mktemp). I don't mind however.
Duh, segfaulting sed! Could you please check which of the sed
invocations actually segfault for you?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Petr Baudis @ 2005-04-22 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vzmvr72j6.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Apr 22, 2005 at 08:23:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
> - Further admit that to support it without core layer help,
> what Cogito layer needs to do involves quite a lot of "yuck"
> factor.
I actually thought that I would just walk to parent directories at the
time of invocation, to find the .git directory, then save that to
$gitdir and use that to always reference to it, setting also
GIT_INDEX_FILE etc. I basically just postponed this until I have some
kind of library or something, and do all this stuff in a single common
init routine. I think it should be doable pretty well in Cogito alone,
but of course I won't mind if someone does it in git core. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: proposal: delta based git archival
From: Jaime Medrano @ 2005-04-22 9:49 UTC (permalink / raw)
To: Michel Lespinasse; +Cc: git
In-Reply-To: <20050422090341.GC22479@zoy.org>
On 4/22/05, Michel Lespinasse <walken@zoy.org> wrote:
> I noticed people on this mailing list start talking about using blob deltas
> for compression, and the basic issue that the resulting files are too small
> for efficient filesystem storage. I thought about this a little and decided
> I should send out my ideas for discussion.
>
I've been thinking in another simpler approach.
The main benefit of using deltas is reducing the bandwith use in
pull/push. My idea is leaving the blob storage as it is by now and
adding a new kind of object (remote) that acts as a link to an object
in another repository.
So that, when you rsync, you don't have to get all the blobs (which
can be a lot of data), but only the sha1 of the new objects created.
Then a remote object is created for each new object in the local
repository pointing to its location in the external repository.
Once the rsync is done, when git has to access any of the new objects
they can be fetched from the original location, so that only necessary
objects are transfered.
This way, the cost of a sync in terms of bandwith is nearly zero.
I've been working on this, so if you think it to be a good idea, I can
send a patch when I get it fully working.
Regards,
Jaime Medrano.
http://jmedrano.sl-form.com
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Krzysztof Halasa @ 2005-04-22 9:48 UTC (permalink / raw)
To: Chris Mason; +Cc: Linus Torvalds, git
In-Reply-To: <200504211622.48065.mason@suse.com>
Chris Mason <mason@suse.com> writes:
> Shrug, we shouldn't need help from the kernel for something like this.
> git as
> a database hits worst case scenarios for almost every FS.
Not sure.
> 1) subdirectories with lots of files
Correct. But git doesn't search dirs so it's not that bad.
> 2) wasted space for tiny files
... depends on block size. With 2 KB:
defiant:~$ du -s /pub/mirror/linux-2.6.git
88366 /pub/mirror/linux-2.6.git
defiant:~$ du -s --apparent-size /pub/mirror/linux-2.6.git
63400 /pub/mirror/linux-2.6.git
Not bad, is it?
> 3) files that are likely to be accessed together spread across the whole disk
... across the whole filesystem.
Well, probably it isn't best to have git and .iso archives on the same
filesystem.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH] multi item packed files
From: Krzysztof Halasa @ 2005-04-22 9:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chris Mason, git
In-Reply-To: <Pine.LNX.4.58.0504211301240.2344@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And dammit, if I'm the original author and likely biggest power-user, and
> _I_ can't be bothered to use special filesystems, then who can? Nobody.
If someone is motivated enough, and if the task is quite trivial (as it
seems to be) someone may try it. I can see nothing wrong with it as long
as it doesn't affect other people.
> This is why I absolutely do not believe in arguments like "if your
> filesystem doesn't do tail packing, you shouldn't use it" or "if your
> don't have name hashing enabled in your filesystem it's broken".
Of course. But one may consider using a filesystem with, say, different
settings. Or a special filesystem for this task, such as CNFS used by
news servers (it seems news servers do quite the same what git does,
except they also purge old contents, i.e., container files don't grow up).
> I'm perfectly willing to optimize for the common case, but that's as far
> as it goes. I do not want to make fundamental design decisions that depend
> on the target filesystem having some particular feature.
The optimization would be (in) the underlying filesystem (i.e., the OS
thing, or possibly a shared preloaded library?), not git itself.
--
Krzysztof Halasa
^ permalink raw reply
* Re: "GIT_INDEX_FILE" environment variable
From: Zach Welch @ 2005-04-22 9:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504212200400.2344@ppc970.osdl.org>
Howdy,
Linus Torvalds wrote:
> On Thu, 21 Apr 2005, Junio C Hamano wrote:
>>I am thinking about an alternative way of doing the above by
>>some modifications to the git core. I think the root of this
>>problem is that there is no equivalent to GIT_INDEX_FILE and
>>SHA1_FILE_DIRECTORY that tells the core git where the project
>>top directory (i.e. the root of the working tree that
>>corresponds to what $GIT_INDEX_FILE describes) is.
>
> I'd _really_ prefer to just try to teach people to work from the "top"
> directory instead.
Would it be okay if that were settable on a per-repository basis? :)
Or do you have specific subset of operations you want restricted?
>> - A new environment variable GIT_WORKING_TREE points at the
>> root of the working tree.
[snip]
> I really don't like it that much, but to some degree it obviously is
> exactly what "--prefix=" does to checkout-cache. It's basically saying
> that all normal file operations have to be prefixed with a magic string.
I'm going to script it one way or the other, but the environment route
allows me to set things up after a fork and before exec in Perl. This
works regardless of what git command I'm running, and should work even
with ithreads. This ease of use would not be the case with the
'--prefix' solution, as scripting the commands would requiring passing
arguments to those commands that need/support them at a higher level
than is desirable.
At present, I have implemented Yogi to support being able to run
commands from a different working directory than the root of the
repository, and that behavior might be per-repository settable
(someday). If I had my way, I would like to see git support the
following variables:
GIT_WORKING_DIRECTORY - default to '.'
GIT_CACHE_DIRECTORTY - default to ${GIT_WORKING_DIRECTORY}/.git
GIT_OBJECT_DIRECTORY - defaults to ${GIT_CACHE_DIRECTORY}/objects
The reasoning is simple: One object repository can be shared among
numerous working caches, which can be shared among multiple working
directories (e.g. any directories under the project root, but maybe also
import/exports, or other magic...). There are two layers of one to many
relationships between the three classes of directories, and my scripts
want to make use of that flexibility to the hilt.
Also, do you really think git will only ever have the index file, and
not someday possibly other related bits? (You may have said that
elsewhere, but I missed it.) If that's ever the case, the directory
variable is the way to go; scripts can be forward compatible and won't
risk accidentally mingling repository data when their scripts have only
set GIT_INDEX_FILE and not GIT_SOME_OTHER_FILE.
That said, I think GIT_INDEX_FILE would supplement the above scheme
nicely, overriding a default of ${GIT_CACHE_DIRECTORY}/index, because of
use cases you've described.
Cheers,
Zach
^ permalink raw reply
* Re: proposal: delta based git archival
From: Jeffrey E. Hundstad @ 2005-04-22 9:12 UTC (permalink / raw)
To: Michel Lespinasse; +Cc: git
In-Reply-To: <20050422090341.GC22479@zoy.org>
Michel Lespinasse wrote:
>Does this sound insane ? Too complicated maybe ?
>
>
My vote is YES on both counts.
Simplicity and flexibility is what makes git a good thing; and imho this
works against that quite aggressively.
--
Jeffrey Hundstad
^ permalink raw reply
* proposal: delta based git archival
From: Michel Lespinasse @ 2005-04-22 9:03 UTC (permalink / raw)
To: git
I noticed people on this mailing list start talking about using blob deltas
for compression, and the basic issue that the resulting files are too small
for efficient filesystem storage. I thought about this a little and decided
I should send out my ideas for discussion.
In my proposal, the current git object storage model (one compressed object
per file) remains as the primary storage mechanism, however there would be
some kind of backup mechanism based on multiple deltas grouped in one file.
For example, suppose you're looking for an object with a hash of
eab75ce51622aa312bb0b03572d43769f420c347
First you'd look at .git/objects/ea/b75ce51622aa312bb0b03572d43769f420c347 -
if the file exists, that's your object.
If the file does not exist, you'd then look for .git/deltas/ea/b,
.git/deltas/ea/b7, .git/deltas/ea/b75, .git/deltas/ea/b75c, ...
up to some maximum search path lenght. You stop at the first file you can
find.
Supposing that file is .git/deltas/ea/b7, it would contain a diff
(let's assume unified format for now, though ideally it'd be better to
have something that allows binary file deltas too) of many archived
objects with hashes starting with eab7, compared to a different object
(presumably some direct or indirect ancestor):
diff -u 8f5ba0203e31204c5c052d995a5b4449226bcfb5 eab75ce51622aa312bb0b03572d43769f420c347
--- 8f5ba0203e31204c5c052d995a5b4449226bcfb5
+++ eab75ce51622aa312bb0b03572d43769f420c347
@@ -522,7 +522,7 @@
....
diff -u 77dc2cb94930017f62b55b9706cbadda8c90f650 eab71c51dbc62797d6c903203de44cc6a734c05c
--- 77dc2cb94930017f62b55b9706cbadda8c90f650
+++ eab71c51dbc62797d6c903203de44cc6a734c05c
@@ -560,13 +563,17 @@
...
Based on this delta file, we'd then look for the object
8f5ba0203e31204c5c052d995a5b4449226bcfb5 (this process could require
recursively rebuilding that object) and try to build
eab75ce51622aa312bb0b03572d43769f420c347 by applying the delta and then
double checking the hash.
To me the strenghts of this proposal would be:
* It does not muddy the git object model - it just acts independently of it,
as a way to rebuild git objects from deltas
* Old objects can be compressed by creating a delta with a close ancestor,
then erasing the original file storage for that object. The object delta
can be appended to an existing delta file (which avoids the small-file
storage issue), or if the delta file gets too big, it can be split off
into 16 smaller files based on the hashes of the objects this file stores
deltas for.
* The system is flexible enough to explore different delta
strategies. For example one could decide to keep one object every 10
in the database and store other 9 as deltas based on the immediate
object ancestor, or any other tradeoff - and the system would still
work the same (with different performance tradeoffs though).
Does this sound insane ? Too complicated maybe ?
Is there any kind of semi-standard binary-capable multiple-file diff format
that could be used for this application instead of unified diffs ?
--
Michel "Walken" Lespinasse
"Bill Gates is a monocle and a Persian cat away from being the villain
in a James Bond movie." -- Dennis Miller
^ permalink raw reply
* [RFC] Is there a need for binary bit in cache/tree entries to properly support Cygwin builds of GIT?
From: Jon Seymour @ 2005-04-22 8:53 UTC (permalink / raw)
To: lode leroy; +Cc: git
In-Reply-To: <BAY22-F35C035C6AE6B9A45CDEF61FF2D0@phx.gbl>
On 4/22/05, lode leroy <lode_leroy@hotmail.com> wrote:
> I wonder if anyone is interested in using git on windows / cygwin.
> It almost compiles out of the box... just this one little thinggy
> that's glibc-specific (struct dirent . d_type)
>
I wonder if a cygwin compile of GIT should be forced to strip CR's
from text files prior to checksum calculations and blob storage.
Otherwise, spurious differences may be introduced into text files that
are somehow munged while checked out in a Windows environment.
There is an argument that this should be done external to the GIT
core, but then every external non-unix tool that interacts with GIT
has to have heuristics to distinguish text from binary and they all
have to have the same heuristics.
So, perhaps there is an argument for using one of the unused "mode"
bits to encode a binary flag and add an option to update-cache that
allows the bit to be flipped if a blob is known to be binary. A cygwin
GIT binary could then be forced to strip CR's from blobs marked as
text, but a unix binary need not change its behaviour.
Regards,
jon.
^ permalink raw reply
* (nearly trivial) patch to compile git on cygwin
From: lode leroy @ 2005-04-22 8:09 UTC (permalink / raw)
To: git
I wonder if anyone is interested in using git on windows / cygwin.
It almost compiles out of the box... just this one little thinggy
that's glibc-specific (struct dirent . d_type)
~/pkg $ diff -bruw git-0.6 git-0.6-cyg | grep -v ^Only
diff -bruw git-0.6/Makefile git-0.6-cyg/Makefile
--- git-0.6/Makefile 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-cyg/Makefile 2005-04-22 09:28:54.259531200 +0200
@@ -30,7 +30,7 @@
$(LIB_FILE): $(LIB_OBJS)
$(AR) rcs $@ $(LIB_OBJS)
-LIBS= $(LIB_FILE) -lssl -lz
+LIBS= $(LIB_FILE) -lssl -lz -lcrypto
init-db: init-db.o
diff -bruw git-0.6/show-files.c git-0.6-cyg/show-files.c
--- git-0.6/show-files.c 2005-04-21 19:58:47.000000000 +0200
+++ git-0.6-cyg/show-files.c 2005-04-22 10:03:04.227240000 +0200
@@ -61,26 +61,33 @@
continue;
len = strlen(de->d_name);
memcpy(fullname + baselen, de->d_name, len+1);
+#ifdef DT_DIR
switch (de->d_type) {
+#endif
struct stat st;
+#ifdef DT_DIR
default:
continue;
case DT_UNKNOWN:
+#endif
if (lstat(fullname, &st))
continue;
if (S_ISREG(st.st_mode))
break;
if (!S_ISDIR(st.st_mode))
continue;
+#ifdef DT_DIR
/* fallthrough */
case DT_DIR:
+#endif
memcpy(fullname + baselen + len, "/", 2);
read_directory(fullname, fullname, baselen +
len + 1);
continue;
+#ifdef DT_DIR
case DT_REG:
break;
}
+#endif
add_name(fullname, baselen + len);
}
closedir(dir);
~/pkg $
_________________________________________________________________
^ permalink raw reply
* Re: [PATCH] #!/bin/sh --> #!/usr/bin/env bash
From: H. Peter Anvin @ 2005-04-22 7:37 UTC (permalink / raw)
To: Alecs King; +Cc: git
In-Reply-To: <20050421194255.GA8479@alc.bsd.st>
Alecs King wrote:
>
> And as for bash, only gitdiff-do and gitlog.sh 'explicitly' use bash
> instead of /bin/sh. On most Linux distros, /bin/sh is just a symbolic
> link to bash. But not on some others. I found gitlsobj.sh could not
> work using a plain /bin/sh on fbsd. To make life easier, i think it
> might be better if we all explicitly use bash for all shell scripts.
>
How about #!/bin/bash (build from .in files if you feel it necessary to
support systems which don't have bash in /bin) instead of doubling the
number of execs?
-hpa
^ permalink raw reply
* Re: Mozilla SHA1 implementation
From: Paul Mackerras @ 2005-04-22 7:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504211238150.2344@ppc970.osdl.org>
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?
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.
Paul.
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Barry K. Nathan @ 2005-04-22 7:24 UTC (permalink / raw)
To: Barry K. Nathan; +Cc: Petr Baudis, git
In-Reply-To: <20050422071626.GB8467@ip68-225-251-162.oc.oc.cox.net>
On Fri, Apr 22, 2005 at 12:16:26AM -0700, Barry K. Nathan wrote:
> With git-pasky 0.6.3, "git log" is unusable on my Mandrake 10.1 system.
> Basically I get a neverending flood of these until I press 'q' to quit
> less:
[snip sed segmentation faults which happen with 0.6.3 but not 0.6.2]
> I'm not sure if I have time tonight (or tomorrow) to troubleshoot this
> further, but I'll see if I can.
I had sed-4.1.1-2mdk. I downloaded sed-4.1.4-2mdk (from Mandriva 2005
Limited Edition) and updated to that, and the problem went away.
FWIW this is the second package I've had to update to the Mandriva 2005
LE level (the first was mktemp). I don't mind however.
-Barry K. Nathan <barryn@pobox.com>
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.6.3 && request for testing
From: Barry K. Nathan @ 2005-04-22 7:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050422030931.GA14565@pasky.ji.cz>
With git-pasky 0.6.3, "git log" is unusable on my Mandrake 10.1 system.
Basically I get a neverending flood of these until I press 'q' to quit
less:
/home/barryn/softbag/git-pasky-0.6.3/gitlog.sh: line 73: 7598 Segmentation faul
t sed -re '
/ *Signed-off-by.*/Is//'$colsignoff'&'$c
oldefault'/
s/^/ /
'
/home/barryn/softbag/git-pasky-0.6.3/gitlog.sh: line 73: 7609 Segmentation faul
t sed -re '
/ *Signed-off-by.*/Is//'$colsignoff'&'$c
oldefault'/
s/^/ /
'
/home/barryn/softbag/git-pasky-0.6.3/gitlog.sh: line 73: 7620 Segmentation faul
t sed -re '
/ *Signed-off-by.*/Is//'$colsignoff'&'$c
oldefault'/
s/^/ /
'
git-pasky-0.6.2 works fine.
I'm not sure if I have time tonight (or tomorrow) to troubleshoot this
further, but I'll see if I can.
-Barry K. Nathan <barryn@pobox.com>
^ 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