git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* Re: dumb transports not being welcomed..
  2005-09-13 22:29 10%       ` Linus Torvalds
@ 2005-09-13 22:37  0%         ` Junio C Hamano
  0 siblings, 0 replies; 6+ results
From: Junio C Hamano @ 2005-09-13 22:37 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Sam Ravnborg, git

Linus Torvalds <torvalds@osdl.org> writes:

> You do realize that up until a week ago (six days, to be exact),
> kernel.org was running git-0.99.4, which I don't think actually
> implemented any of the info stuff?

Ah, no I didn't.  For future reference, how can I find that kind
of thing myself (not "what was not in 0.99.4", but "what did
kernel.org run a week ago")?

> Dumb protocols can never do really well. That's just very fundamental. 

I agree.  I am waiting for git-deamon to happen on kernel.org,

I am hoping there won't be much problems but am somewhat worried
that customized packing for each client might turn out to be too
much load.

^ permalink raw reply	[relevance 0%]

* Re: dumb transports not being welcomed..
  @ 2005-09-13 22:29 10%       ` Linus Torvalds
  2005-09-13 22:37  0%         ` Junio C Hamano
  0 siblings, 1 reply; 6+ results
From: Linus Torvalds @ 2005-09-13 22:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Sam Ravnborg, git



On Tue, 13 Sep 2005, Junio C Hamano wrote:
> 
> I need to clarify what I meant by 'not welcoming dumb transport'
> a bit better.  Namely, those (~80 - 23) = ~57 repositories lack
> support for 'git ls-remote' over http, which means you cannot
> discover what refs the repository has.

You do realize that up until a week ago (six days, to be exact),
kernel.org was running git-0.99.4, which I don't think actually
implemented any of the info stuff?

So out of the 57 repositories, how many haven't been updated in a week?

I suspect that explains a large portion of it.

Also, I really do think that the dumb transports are oversold, and 
git-daemon is undersold. I know all about firewalls, but I also think that 
if people used the smart protocols more, that's a problem that would 
largely solve itself. 

Dumb protocols can never do really well. That's just very fundamental. 

		Linus

^ permalink raw reply	[relevance 10%]

* Re: What's up with the GIT archive on www.kernel.org?
  @ 2005-09-11 19:56 11%         ` Linus Torvalds
  0 siblings, 0 replies; 6+ results
From: Linus Torvalds @ 2005-09-11 19:56 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: Peter Osterlund, Linux Kernel Mailing List, Git Mailing List



On Sun, 11 Sep 2005, Sam Ravnborg wrote:
> 
> I had to specify both GIT_DIR and GIT_OBJECT_DIRECTORY to make
> git-prune-packed behave as expected. I assume this is normal when I
> rename the .git directory like in this case.

You should only need to specify GIT_DIR - it should figure out that the 
object directory follows GIT_DIR on its own.

Also, I forget what version of git is installed on kernel.org. The
"alternates" support has been around for a while, and looking at the date
of "/usr/bin/git" it _seems_ recent (Sep 7), but I haven't seen any
announcement of updating since the last one (which was git-0.99.4, which
is too old).

You can try removing all the packs in your .git/objects/packs directory. 
Everything _should_ still work fine.

Famous last words.

		Linus

^ permalink raw reply	[relevance 11%]

* GIT 0.99.4 preview: current status
  2005-08-07  6:00 11% ` GIT 0.99.4 (preview) Junio C Hamano
  2005-08-08  3:18  9%   ` Horst von Brand
@ 2005-08-08  9:09 14%   ` Junio C Hamano
  1 sibling, 0 replies; 6+ results
From: Junio C Hamano @ 2005-08-08  9:09 UTC (permalink / raw)
  To: git

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

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

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

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

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

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

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

Horst von Brand:
  RPM spec updates.

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

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

Kalle Valo:
  Fix debian doc-base

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

Nicolas Pitre:
  list shortlog items in commit order

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

Petr Baudis:
  Fix git-merge-cache -q

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

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

^ permalink raw reply	[relevance 14%]

* Re: GIT 0.99.4 (preview)
  2005-08-07  6:00 11% ` GIT 0.99.4 (preview) Junio C Hamano
@ 2005-08-08  3:18  9%   ` Horst von Brand
  2005-08-08  9:09 14%   ` GIT 0.99.4 preview: current status Junio C Hamano
  1 sibling, 0 replies; 6+ results
From: Horst von Brand @ 2005-08-08  3:18 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

My proposed patch, the description as is is misleading.

The rest of the .spec file looks sane (yes, I've built my share of RPMs
over the years).

diff --git a/git-core.spec.in b/git-core.spec.in
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -2,7 +2,7 @@
 Name: 		git-core
 Version: 	@@VERSION@@
 Release: 	1
-Vendor: 	Linus Torvalds <torvalds@osdl.org>
+Vendor: 	Junio C Hamano <junkio@cox.net>
 Summary:  	Git core and tools
 License: 	GPL
 Group: 		Development/Tools
@@ -13,22 +13,23 @@ BuildRoot:	%{_tmppath}/%{name}-%{version
 Prereq: 	sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
 
 %description
-GIT comes in two layers. The bottom layer is merely an extremely fast
-and flexible filesystem-based database designed to store directory trees
-with regard to their history. The top layer is a SCM-like tool which
-enables human beings to work with the database in a manner to a degree
-similar to other SCM tools (like CVS, BitKeeper or Monotone).
+This is a stupid (but extremely fast) directory content manager.  It
+doesn't do a whole lot, but what it _does_ do is track directory
+contents efficiently. It is intended to be the base of an efficient,
+distributed source code management system. This package includes
+rudimentary tools that can be used as a SCM, but you should look
+elsewhere for tools for ordinary humans layered on top of this.
 
 %prep
 %setup -q
 
 %build
-
 make prefix=%{_prefix} all %{!?_without_docs: doc}
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} install install-tools %{!?_without_docs: install-doc}
+make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} \
+     install install-tools %{!?_without_docs: install-doc}
 
 %clean
 rm -rf $RPM_BUILD_ROOT
@@ -43,7 +44,13 @@ rm -rf $RPM_BUILD_ROOT
 %{!?_without_docs: %{_mandir}/man7/*.7.gz}
 
 %changelog
+* Sun Aug 07 2005 Horst H. von Brand <vonbrand@inf.utfsm.cl>
+- Redid the description
+- Cut overlong make line, loosened changelog a bit
+- I think Junio (or perhaps OSDL?) should be vendor...
+
 * Thu Jul 14 2005 Eric Biederman <ebiederm@xmission.com>
 - Add the man pages, and the --without docs build option
+
 * Wed Jul 7 2005 Chris Wright <chris@osdl.org>
 - initial git spec file

-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[relevance 9%]

* GIT 0.99.4 (preview)
  @ 2005-08-07  6:00 11% ` Junio C Hamano
  2005-08-08  3:18  9%   ` Horst von Brand
  2005-08-08  9:09 14%   ` GIT 0.99.4 preview: current status Junio C Hamano
  0 siblings, 2 replies; 6+ results
From: Junio C Hamano @ 2005-08-07  6:00 UTC (permalink / raw)
  To: git

I said:

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

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

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

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

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

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

^ permalink raw reply	[relevance 11%]

Results 1-6 of 6 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2005-08-06  1:52     My Itchlist Junio C Hamano
2005-08-07  6:00 11% ` GIT 0.99.4 (preview) Junio C Hamano
2005-08-08  3:18  9%   ` Horst von Brand
2005-08-08  9:09 14%   ` GIT 0.99.4 preview: current status Junio C Hamano
     [not found]     <m3mzmjvbh7.fsf@telia.com>
     [not found]     ` <Pine.LNX.4.58.0509110908590.4912@g5.osdl.org>
     [not found]       ` <20050911185711.GA22556@mars.ravnborg.org>
2005-09-11 19:06         ` What's up with the GIT archive on www.kernel.org? Linus Torvalds
2005-09-11 19:46           ` Sam Ravnborg
2005-09-11 19:56 11%         ` Linus Torvalds
2005-09-13 21:07     dumb transports not being welcomed Junio C Hamano
2005-09-13 21:14     ` Sam Ravnborg
2005-09-13 21:30       ` Junio C Hamano
2005-09-13 22:11         ` Junio C Hamano
2005-09-13 22:29 10%       ` Linus Torvalds
2005-09-13 22:37  0%         ` Junio C Hamano

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).