repo.or.cz wishes?

  Hi,

  I've just finally killed the HTTP auth for project administration that
was destroying everyone's lives, and added support for resetting
forgotten passwords, two main things that seemed to be the popular nits
of the repo.or.cz audience.

  So now I wonder, what is the thing you miss most there? Any cool stuff
repo.or.cz could (preferrably easily) do and doesn't?

  And please don't ask for smaller roundtrip times of requests for
administrator assistance. ;-)

  Thanks,

On Mon, Aug 27, 2007 at 01:59:44AM +0200, Petr Baudis wrote:

Just a minor nit, but how about dropping the "git+" from the Push URL?

Jakub was also talking about support in gitweb for specifying the location of submodules. It would be nice if admins could set this information, wherever it ends up getting stored.

skimo

On Mon, Aug 27, 2007 at 02:16:34AM CEST, Sven Verdoolaege wrote:

I'm a major proponent of the "git+" - it's just the correct thing to specify. ssh:// by itself means secure _shell_, and that's not what the URL means - ssh is literaily just a transport layer for the git protocol. This is not my invention but fairly standard thing which plenty of people use, and it makes it possible to select proper protocol handlers and so on, shall something generic crunch on the URL. I've never actually understood why do some people dislike it.

Hmm, this shouldn't be very hard to do if the support will get into gitweb. And adding the support to gitweb shouldn't be that hard either. :-) OTOH, it's not something that would get me terribly excited, so I guess I'll wait for the gitweb side.

On Mon, 27 Aug 2007, Petr Baudis wrote:

I'd say "only", not "major".

It makes no sense.

No it isn't, and no it doesn't.

It makes no sense what-so-ever.

"ssh://" is the *protocol*. What is actually done over the protocol is specified by the program.

This is not at all git specific. Try running "ssh" vs "scp" some day, and you'll notice the exact same thing: they both use the ssh _protocol_, but no, your statement that "ssh://" by itself means "secure _shell_" is total and utter garbage.

It means nothing at all of the kind. 

"ssh://" means the ssh protocol. It is that unambiguous, and that simple. Saying "git+ssh://" is totally idiotic, always has been, and always will be.

It's as stupid as it would be to require people to say

	scp cp+ssh://host/filename .

and nobody sane would *ever* advocate something that stupid. It's not how it's done.

So why do you continue to advocate "git+ssh://", when nobody else does, and several people have asked you not to.

And yes, I realize that SVN does it. SVN for some unfathomable reason uses "svn+ssh://", but let's face it, the SVN developers have neither taste nor brains. They don't know any better.

			Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

Chuckles...

I'd rather see hostname:/path/to/file on the page as it tends to be even shorter.

Linus Torvalds <torvalds@linux-foundation.org> writes:

You could find a better example.

scp doesn't accept URL syntax at all. So, no, it doesn't know about cp+ssh://, but doesn't know ssh:// either.

Hello, world!\n

Really?

What does `ssh://what.the.hell.org/some/file' per se mean?

SSH is a protocol, but rather in the sense similar to TLS, not to HTTP. If it has some addressable objects, which could be referred to by the path part of the URL, they should be the programs to execute at the remote server, i.e., in our case the path to the GIT client binary, and certainly not the name of the repository, which has nothing to do with the SSH protocol.

(Just for completeness: I do not advocate using git+ssh, but your arguments against it look somewhat illogical.)

				Have a nice fortnight

Quoting Martin Mares <mj@ucw.cz>:

Not to advocate either way (me being completely new to git), but as far as ssh is concerned, I don't think that the addressable objects necessarily have to be executables.

Quoting RFC4251: "The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network."

That reads rather vague to me.

On Mon, 27 Aug 2007, Martin Mares wrote:

So what does "http://what.the.hell.org/some/file" mean?

Does it mean that you have to start a web browser? Should we make that be

	git+http://what.the.hell.org/some/file

to make it clear that we're doing "git work" over the "http" protocol?

Pretty obviously not.

What does *that* mean? A protocol is a protocol. Your argument that protocols are "different" is pointless. Some protocols are usable for git, others aren't. OF COURSE different protocols are different. They are different in different ways.

Git uses URL's to say how to access something, which includes a protocol, an optional host, and a location within the host. It's quite obvious what they mean, and it's *also* obvious that the meaning is git-specific.

Here's what it boils down to:

 - do you think it is sensible to write

	git clone git+file:///some/directory
	git clone git+http://host/directory
	git clone git+rsync://host/directory

   when cloning from the local filesystem, over http, or over rsync 
   respectively? The first one, btw, actually uses the "git protocol". The 
   two others do not, but since a user shouldn't care, it would be really 
   stupid to try to make some internal implementation detail show up in 
   the URL scheme.

 - if you really think that the above is sensible, then explain why.

 - if you think that is TOTALLY IDIOTIC, then explain why "ssh://" is so 
   magically special that it would somehow make sense to say "git+" for 
   it?

As to your TLS example: if we were to do "git over TLS", it would make perfect sense to use either "tls://" (although "gits://" might be more natural, not because tls is wrong, but because people have gotten used to "https://") if we were to have a "secure git" port. Or maybe we'd use the same port number that we already have assigned for git, and just add some "use TLS to authenticate/encrypt", and use "tls://" for that. It makes perfect sense.

In short: you should just ask yourself: what is the most natural thing for a *user* to type to "git clone". And no, the "git+" prefix never makes sense.

			Linus

Linus Torvalds wrote:

This is also useful for foreign SCM support; the idea of supporting svn+ssh:// "directly" with git remote and the likes.

I don't usually write git+ssh://, but I do consider it to be the form which is more in the spirit of application interoperability. It says what it is, which is ssh tunnelled git protocol.

The scheme is bad because it doesn't integrate with other appliations. Seeing the URI in a web page they have no way of knowing which application or port this tls:// URI refers to. It's not *universal*.

This is fine for URIs passed into git, but bad if you want to link to it from elsewhere.

Sam.

On Tue, 28 Aug 2007, Sam Vilain wrote:

..and by that logic, you should add "git+" to *everything*, not just ssh.

Which simply isn't practical or sane - only damn annoying.

			Linus

Linus Torvalds wrote:

Not exactly. You can browse using http:// and file:// protocols, rsync:// is simply rsync, while ssh:// (or git_ssh://) can be limited using git-shell.

On Tue, 28 Aug 2007, Jakub Narebski wrote:

Bullshit. You carefully left out "git://", since that doesn't fit your "argument".

The fact is, all git URL's make sense for *git*, not necessarily for anything else. They may have incidental meanings outside of git, but certainly nothing that is really *sensible*.

And that is how it was designed to be. The URL's are for *git*, not for other uses. If you want to do cross-SCM tools, you need to let them know it's a "git" thing wheher it's browsable or not, so the argument that ssh is something "different" is bogus crapola.

Just face it, ssh is in no way different from any of the other git URL specifiers.

			Linus

Linus Torvalds wrote:

Why annoying and impractical, if you don't ever have to specify it unless you want to write a URI which is portable between applications?

Sam.

On Tue, 28 Aug 2007, Sam Vilain wrote:

Sure. I'm perfectly happy to make connect.c just ignore any "git+" prefix, and let people do it.

What I object to is:
 - the totally *idiotic* notion that "ssh" is somehow different
 - encouraging people to actually *use* that inconvenient format

The fact is, nobody really cares. We've happily used the non-"git+" forms for over two years, and there has never *ever* been a case of actual confusion. So allowing the "git+" prefix everywhere may be _logical_, but it's still totally idiotic and user-unfriendly.

		Linus

Linus Torvalds wrote:

I like gits:// idea for "git over TLS", and I'm against "tls://". I wonder if it would be hard to implement "git overt TLS"? We could resurrect patch which allowed push over git protocol, onnly restricting pushing to gits protocol.

On Monday, 27 August 2007, Petr "Pasky" Baudis wrote:

Is it now possible to _upload_ SSH key, instad of copy'n'paste it when creating repository/account?

Would it be reasonable to limit repository name length, or at least modify gitweb to truncate (cut) it if it is too long?

First, it is in the context of git, so one can say that "git+" is implied. Documentation mentions only "ssh://". That said I prefer "git+ssh://" to "ssh://" alone.

Second, IIRC Linus prefers scp-like syntax for SSH protocol, namely "[user]@host:/path/to/repo", so perhaps that one should be used instead.

The problem is that repo.or.cz needs support for that in gitweb, while gitweb in turn needs support for that in git. This needs git consensus on how to specify object database location (or just gitdir) for submodules, to have later submodule support in gitweb.

Petr Baudis wrote:

I'd like to see the service mirrored, including potentially a repository which contains the meta/auth information (sans password hashes, perhaps) for admins on accounts.

This of course opens a large can of worms when it comes to achieving decentralization of the service as a whole, however I think those questions will be best answered once the information is available for setting up mirrors.

I've also got hardware, bandwidth and some tuits.

Sam.

Hi,

On Mon, 27 Aug 2007, Petr Baudis wrote:

I wonder if this is repo.or.cz specific, but we recently had a problem where the blobs of a project went away, and the forked project still relied on them. Any ideas how to solve that issue?

Ciao, Dscho

Hello Petr,

Petr Baudis wrote:

I have two wishes (even though I don't use repo.or.cz regularly).

- searching for sha1 id.
  OK, I know how to create an URL for that, but that's inconvient.

- When looking on forks of say git.git, I want the "main" project shown,
  too.  That is http://repo.or.cz/w/git.git?a=forks should include a
  link to http://repo.or.cz/w/git.git.

After rereading these may more be gitweb wishes than repo.or.cz, but anyhow ...

Best regards Uwe

On Tue, Aug 28, 2007 at 11:56:10PM +0200, Jakub Narebski wrote:

Ah... you're talking about bare repositories, right? For non-bare repos, I'd assume you would only recurse for those submodules that you have actually checked out in your working tree.

skimo

On Wed, Aug 29, 2007, Sven Verdoolaege wrote:

For bare repositories, and for repositories which move around (at least once change path). Gitweb uses repository like it is bare...

On Wed, Aug 29, 2007 at 06:20:05AM CEST, Shawn O. Pearce wrote:

I don't handle it at all, but if you don't have permissions to modify A you simply won't be able to do anything weird to A. If you have the permissions, I'm still not sure if Git will keep symlinked refs over ref updates; if so, hey, you had the permissions for A and it's your reponsibility if you screw up.

On Wed, Aug 29, 2007 at 07:08:21AM CEST, Junio C Hamano wrote:

BTW gitweb actually uses refs/forkee/ to add funny ref tags to commits, which was completely unintended but is actually in the end quite handy (though the tags should be modified to look less confusing).

On Wed, Aug 29, 2007 at 12:15:23AM -0400, Shawn O. Pearce wrote:

But "git-gc" without the --prune doesn't delete any objects. So it should always be safe to use git-gc even if there are repositories that are relying on that repo's ODB. It's only if you use git-gc --prune that you could get in troudble. It might delete some packfiles containing objects needed by B, but only after consolidating all of the objects into a single packfile that contains all of the objects that had always been in A's ODB.

So I don't see why this wouldn't work.

						- Ted

Theodore Tso <tytso@mit.edu> wrote:

Yes, it does delete objects. Even without --prune. That is because git-gc is running `git-repack -a -d -l`. repack -a means repack all objects reachable from the current refs. The -d means delete the packfiles that existed when the repack started, as it is assumed that all needed (reachable) objects were copied into the new output packfile(s). The -d also means delete any loose objects that are now packed (git-prune-packed).

Yet there may be objects in A that A cannot reach anymore (deleted or rewound branch) but that B needs and B does not have a copy of. If these objects were in one of the prior packfiles of A and is not in the new packfile(s) of A then those objects are gone. *poof*.

But when we repack we don't repack everything in A's ODB, we only
repack the things that A can reach.  If A cannot reach something
because a branch was rewound or deleted it won't survive the repack.
Then the repack is behaving like at least partially like gc --prune.
 

It only works if A cannot delete a branch or rewind a branch. In other words, once an object is stored in A's ODB it must always be reachable from A's refs.

On Wed, 29 Aug 2007, Shawn O. Pearce wrote:

Now, this doesn't work well with packed refs, I'm afraid.

So I suspect that if we really want to support something like this, we'd need to do more than just avoid the recursion when you cross-link.

		Linus

Linus Torvalds <torvalds@linux-foundation.org> wrote:

No, it doesn't work well.  So I actually also avoid packing A's refs.
Which is yet another reason why my A's don't allow pushing, that
way nobody goes nuts and creates a ton of refs in there.  With only
refs/heads/master and it being unpacked its not a big deal.
 

Yes. I've been thinking about trying to better share the ODB and the ref database between repositories, but it has been low priority for me.

I rely on this ref symlinking/alternate ODB trick a lot at day-job to help me cope with an ugly situation I created across a number of repositories. Most of our codebase came from one Git repository, but has been refactored and split into about 10 different Git repositories. I did that refactoring by just cloning and deleting the uninteresting content, so each repository actually has a huge block of its history in common with the other 9.

One such A is "common-crap.git" that is the shared common history. Since its strictly history nobody changes that repository, and everyone borrows objects from it. This reduces my common working set by about 900MiB, as the history lives in only one packfile and not in 10.

There are obviously other ways to deal with this:

 - start the 10 repositories over again and use info/grafts to
   reinsert the old history when/if required;

 - just hardlink the same .keep'd packfile into the 10 repositories,
   since it is held by .keep it won't be touched during repack.

So one reason it has been low priority for me to improve upon is because there's more than one way to solve the problem, and the particular solution I have settled upon may not be the best solution for anyone.

Though I think we can all agree that repo.or.cz's use of forks is increasingly more popular, and one of the more powerful social features of git. Better supporting it out of the box by making it easier to setup and manage can only be a good thing for our users.