Re: please pull ppc64-2.6.git
Russell King [EMAIL PROTECTED] writes: Is the expected filesystem layout documented somewhere online (_external_ to the source code) ? There already was a sketchy description in git(7), at http://www.kernel.org/pub/software/scm/git/docs/ I've updated it a bit to describe the current status; please look for File/Directory Structure section of the above URL. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
On Tue, 30 Aug 2005 15:25:22 -0700 Junio C Hamano wrote: Christian Meder [EMAIL PROTECTED] writes: Is alternates unthinkable with URLs (e.g. remote alternates). In order to read an object data, the low level core GIT layer does open()/mmap() of a file on the locally mounted filesystem. It also does opendir()/readdir()/closedir() to find what's available. If you can arrange to automount via luserfs (or whatever; we do not care much about particular implementation) so that it can do these filesystem operations, git will happily use it. Even in that case, the alternate you would tell git should look like a local filesystem path --- your automounting from remote specified with URL for such a path would happen outside GIT. All this means that currently there is no clean way to publish a partial GIT repository, unless you place it at the same server where the base repository is located (and even in that case needing to use something like echo /pub/scm/linux/kernel/git/torvalds/linux-2.6/objects objects/info/alternates looks like a horrible hack). What if we create a mapping layer from URLs to local mirrors of corresponding repositories? Store this mapping, e.g., in ~/.git-core/mirrors, then if git reads an URL instead of an absolute local path from objects/info/alternates, it will consult that file and either use the specified local mirror, or complain that a local copy of the base repository is not available. The partial repository will then contain no system-specific paths and could be published without problems. pgpgbKks1DKX5.pgp Description: PGP signature
Re: please pull ppc64-2.6.git
Sergey Vlasov [EMAIL PROTECTED] writes: All this means that currently there is no clean way to publish a partial GIT repository, unless you place it at the same server where the base repository is located (and even in that case needing to use something like echo /pub/scm/linux/kernel/git/torvalds/linux-2.6/objects objects/info/alternates looks like a horrible hack). There has never been a way to publish a partial GIT repository. I personally am not convinced it is even a good idea for people to be able to do so. $GIT_OBJECT_DIRECTORY/info/alternates is a mechanism to solve completely different issue -- borrowing objects locally from different object store to save space. This is only a local 'repository organization' issue, just like packing objects or leaving them unpacked in a repository _should_ not make any difference to people who are interacting with it. The use of info/alternates is internal to the git aware server side, be it git-daemon and git-upload-pack when somebody fetches from it, or git-receive-pack when somebody pushes into it. The other end _should_ never have to care if the repository uses info/alternates, just like it _shouldn't_ matter if the repository is packed or unpacked. Most importantly, for people who are interacting with it, the repository has _everything_ it claims to have by having pointers to head commits under refs/ hierarchy, and is _not_ partial at all. Yes, you could peek into the remote repository filesystem by other means, and even slurp the info/alternates file via rsync, but as stated many times before, a lot of things that rsync does are by accident not by design. Some historical explanation may be helpful. info/alternates is merely an improvement for existing ALTERNATE_OBJECT_DIRECTORIES mechanism. The latter required individual processes to tell git what other object stores to consult to find missing objects when working on a repository whose object store is a partial object database. This was clearly not per-process information; it was specific to that partial object store, and that was the reason info/alternates was invented. The processes do not have to have that environment variable; instead the necessary information is recorded in the partial object store itself. I kept saying '_should_' because commit walkers would not currently understand alternates, just like they had trouble with packed repositories earlier. This _is_ a defect, but I personally feel that this is a problem not worth solving. Earlier, when commit walkers did not understand packed repositories, the only workaround was 'then do not pack your public repository'. This was unacceptable from storage consumption point of view, and it had to be solved in some way. Daniel solved it for 0.99.4. But what info/alternates does is different. If you care about commit walkers (and I certainly do), there are other means to save space without using info/alternates; first try packing, and then hard linking object files with whichever other repository you would have placed in info/alternates, and you are done. Now you may argue that being able to publish truly partial repository that does not have all the objects and depends on some other repository, very likely to be on completely different server (otherwise you would not be advocating for a non-local path such as URL) a worthwhile goal. I personally do not even believe that a repository relying on a foreign object store is a good idea, and much less so if you are making that repository publicly available. I like your local-mirror-mapping idea very much, but I do not think it is something that is specific to git. If you have such a mechanism to map remote URL into local filesystem namespace and automount/mirror them on demand, I'd like to be able to use that when I am browsing files in my Emacs (yes, there is 'ange-ftp') or even 'cat' files from it. Its more useful that way than limiting its use to only when git wants to find missing object files from its alternate object store. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
On Mon, 29 Aug 2005, Paul Mackerras wrote: Please do a pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/ppc64-2.6.git Gaah. This is not a valid git repository. Guys, if you do partially populated repositories, _please_ make sure that you still make it a valid git repository. These days you can trivially do so by doing a echo /pub/scm/linux/kernel/git/torvalds/linux-2.6/objects objects/info/alternates or similar. That also makes gitweb able to show diffs etc, something it can't do for a broken partial repository. Not pulled, Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
On Mon, Aug 29, 2005 at 10:32:09AM -0700, Linus Torvalds wrote: On Mon, 29 Aug 2005, Paul Mackerras wrote: Please do a pull from: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/ppc64-2.6.git Gaah. This is not a valid git repository. Guys, if you do partially populated repositories, _please_ make sure that you still make it a valid git repository. These days you can trivially do so by doing a echo /pub/scm/linux/kernel/git/torvalds/linux-2.6/objects objects/info/alternates or similar. That also makes gitweb able to show diffs etc, something it can't do for a broken partial repository. Is the expected filesystem layout documented somewhere online (_external_ to the source code) ? The reason I stress external to the code is that some of us do not track git developments. (Except via the ctrl-d method in our mail readers.) Alternatively, when changes occur to the repostory format, please can they be marked with some obvious subject so that folk know when things are going to break? -- Russell King - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
On Mon, 29 Aug 2005, Russell King wrote: Is the expected filesystem layout documented somewhere online (_external_ to the source code) ? Nope, I don't think so. Alternatively, when changes occur to the repostory format, please can they be marked with some obvious subject so that folk know when things are going to break? The only actual filesystem _breakage_ has been the introduction of pack-files (and the old, old _old_ thing where I changed the actual object compression/hashing order). The objects/info/alternates thing is an extension, which allows you to have a partial object store, and point to the rest of it, and still have all the tools understand it and be able to parse the totality of it. So it doesn't break or change old formats, it only allows a new one. (Partial repos have always worked with the rsync protocol, and with the client-side pulling. But that was more of an accident than anything else, and they fundamentally were broken for any real work - gitweb can't show anything really sane, server-side serving - whether anonymous or ssh - doesn't work, etc etc). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
On Mon, Aug 29, 2005 at 11:02:38AM -0700, Linus Torvalds wrote: The objects/info/alternates thing is an extension, which allows you to have a partial object store, and point to the rest of it, and still have all the tools understand it and be able to parse the totality of it. So it doesn't break or change old formats, it only allows a new one. Ah, ok. I thought it was a new requirement, and I had visions of similar complaints about my repositories. Thanks for explaining the situation. -- Russell King - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
Linus Torvalds writes: echo /pub/scm/linux/kernel/git/torvalds/linux-2.6/objects objects/info/alternates Did that (s/linux-2.6/linux-2.6.git/ actually...) What can one put in the alternates file? Just an absolute path, or does a relative path or a URL work too? or similar. That also makes gitweb able to show diffs etc, something it can't do for a broken partial repository. Gitweb still doesn't work; I think someone needs to update the git on *.kernel.org. Paul. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please pull ppc64-2.6.git
On Tue, 30 Aug 2005, Paul Mackerras wrote: What can one put in the alternates file? Just an absolute path, or does a relative path or a URL work too? Only an absolute path. URL's fundamentally do not work, and relative paths end up being parsed as relative to where-ever the user happens to be (and some commands will chdir() into the .git directory, while others will not). For a raw git directory like the ones on master.kernel.org, with a relative pathname (relative to the main git directory itself) the _pulling_ should actually happen to work, since that will be happening in the xxx.git directory using GIT_DIR=.. But anything who uses GIT_DIR=something else from another directory wouldn't be able to use it. That probably includes gitweb, btw. So only do the absolute ones. Maybe we should define some well-specified meaning for relative ones, but it definitely isn't there now. or similar. That also makes gitweb able to show diffs etc, something it can't do for a broken partial repository. Gitweb still doesn't work; I think someone needs to update the git on *.kernel.org. Hmm, yes. kernel.org is at 0.99.4, and the objects/info/alternates thing was done after that. It's in 0.99.5, though, so next time kernel.org updates its git version, it will automagically start working. (And I use my own git installation, so it works fine for me, and I just pulled the thing without problems). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
