{"thread":{"id":"16019","subject":"[RFC] Zit: the git-based single file content tracker","startedAt":"2008-10-23T01:29:08Z","lastAt":"2008-10-26T22:16:14Z","messageCount":38,"participants":["Giuseppe Bilotta","Felipe Oliveira Carvalho","Nguyen Thai Ngoc Duy","Johannes Sixt","Jean-Luc Herren","david@lang.hm","Jakub Narebski","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93755","messageId":"gdok16$vh2$1@ger.gmane.org","threadId":"16019","inReplyTo":null,"subject":"[RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-23T01:29:08Z","receivedAt":"2008-10-23T01:29:08Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"Hello all,\n\none of the common remarks done about git is that since it tracks\ntree contents, it's not the best-suited tool to track a bunch of\nindependent files which happen to be in the same directory.\n\nI've found myself in the situation of wanting to track my changes done\nto one or more 'single' files in a directory (e.g. $HOME), and\ndeciding to use antiquate, clumsy, slow and inefficient but file-based\nRCS (yes, you read that right) over git.\n\nIn other situations (e.g. for my UserJS folder) I ended up using git,\nbut not liking the idea of having things such as tags referring to all\nof my UserJS projects instead of the single file they were inteded\nfor, or having to put 'filename: ' at the beginning of commit messages\njust because the history was shared.\n\nSo today I decided to start hacking at a git-based but file-oriented\ncontent tracker, which I decided to name Zit.\n\nThe principle is extremely simple: when you choose to start tracking a\nfile with Zit,\n\nzit track file\n\nZit will create a directory .zit.file to hold a git repository\ntracking the single file .zit.file/file, which is just a hard link to\nfile.\n\nThe reason for using .zit.file as a non-bare repository rather than\njust a GIT_DIR is that it allows things such as 'git status' to ignore\neverything else. A possible alternative could have been to use\n.zit.file as the GIT_DIR and create an all-encopassing\n.zit.file/info/exclude, but the general idea of having this kind of\ndetached GIT_DIR felt less robust (or maybe I just forgot some\nexport).\n\nI also don't like the idea of the hardlink, first of all because of\nportability problems, and secondly because of the way too many\npossibility that the hardlink broke somewhere along the way. For\nexample, I haven't tested any fancy git commands on my sample zit\nimplementation, and I'm not sure checking out some older version would\nactually work.\n\nIf anybody is intered in trying out my quick hack for the idea,\nthere's a git repository for Zit at git://git.oblomov.eu/zit --beware\nthat nothing past the most elementary uses (i.e. diff, status, log,\ncommit) has been tested yet. Many commands are bound to fail due to\nthe braindead way commands are delegated to git.\n\nSuggestions on the best way to approach the many limits of the\nimplementation are more than welcome.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93772","messageId":"a2075f4c0810230533k46968637o2e087da24caa01b1@mail.gmail.com","threadId":"16019","inReplyTo":"gdok16$vh2$1@ger.gmane.org","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Felipe Oliveira Carvalho","fromEmail":"felipekde@gmail.com","sentAt":"2008-10-23T12:33:22Z","receivedAt":"2008-10-23T12:33:22Z","isPatch":false,"sender":{"key":"felipekde@gmail.com","avatar":"https://gravatar.com/avatar/d3b0d3f3e680016d92159d539a9fcae3057490722dac4e206176bd4cf7e20e1b?d=mp&s=160"},"body":"It sounds interesting. I have some single files that I would like to track\nusing git, zit seems to be a good solution.\n\n--\nFelipe\n"},{"id":"93774","messageId":"fcaeb9bf0810230550t54813c09m3b1984f065732c0@mail.gmail.com","threadId":"16019","inReplyTo":"gdok16$vh2$1@ger.gmane.org","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-10-23T12:50:51Z","receivedAt":"2008-10-23T12:50:51Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/23/08, Giuseppe Bilotta wrote:\n> The principle is extremely simple: when you choose to start tracking a\n> file with Zit,\n>\n> zit track file\n>\n> Zit will create a directory .zit.file to hold a git repository\n> tracking the single file .zit.file/file, which is just a hard link to\n> file.\n\nWhy not use one .zit repo and track each file on each own branch?.\n-- \nDuy\n"},{"id":"93777","messageId":"49007623.1060606@viscovery.net","threadId":"16019","inReplyTo":"gdok16$vh2$1@ger.gmane.org","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-10-23T13:03:31Z","receivedAt":"2008-10-23T13:03:31Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Giuseppe Bilotta schrieb:\n> Zit will create a directory .zit.file to hold a git repository\n> tracking the single file .zit.file/file, which is just a hard link to\n> file.\n\ngit breaks hard links, mind you! (Just in case you check out older\nversions and you wonder why your \"real\" file is not updated).\n\nBut there's a recent patch by Dscho floating around that takes care of the\nhard link case.\n\n-- Hannes\n"},{"id":"93780","messageId":"cb7bb73a0810230628l22871f3bj26cd825e2de99ff9@mail.gmail.com","threadId":"16019","inReplyTo":"49007623.1060606@viscovery.net","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-23T13:28:11Z","receivedAt":"2008-10-23T13:28:11Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Thu, Oct 23, 2008 at 3:03 PM, Johannes Sixt wrote:\n> Giuseppe Bilotta schrieb:\n>> Zit will create a directory .zit.file to hold a git repository\n>> tracking the single file .zit.file/file, which is just a hard link to\n>> file.\n>\n> git breaks hard links, mind you! (Just in case you check out older\n> versions and you wonder why your \"real\" file is not updated).\n>\n> But there's a recent patch by Dscho floating around that takes care of the\n> hard link case.\n\nI feared that the hardlink choice was not the best one. I would\ndefinitely prefer finding a solution that didn't depend on hardlinks:\nnot only there would be no worry about breaking them, it'd also be\nmore portable.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93781","messageId":"cb7bb73a0810230633r9970a50mbb4ecf3a855c3a21@mail.gmail.com","threadId":"16019","inReplyTo":"fcaeb9bf0810230550t54813c09m3b1984f065732c0@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-23T13:33:29Z","receivedAt":"2008-10-23T13:33:29Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy wrote:\n> On 10/23/08, Giuseppe Bilotta wrote:\n>> The principle is extremely simple: when you choose to start tracking a\n>> file with Zit,\n>>\n>> zit track file\n>>\n>> Zit will create a directory .zit.file to hold a git repository\n>> tracking the single file .zit.file/file, which is just a hard link to\n>> file.\n>\n> Why not use one .zit repo and track each file on each own branch?.\n\nSo your proposal is to have a single .zit repo which is actually a git\nrepo and where each additional tracked file becomes its own branch,\nand zit would take care of switching from branch to branch when zit\ncommands are called?\n\nI think this solution would have a number of problems, apart from\nbeing generally quite messy. First of all, moving a file and its\nhistory somewhere else means toying around with the history of a much\nwider repo, whereas the current approach would mean just moving the\n.zit.file dir together with the file (modulo hardlinks). Non-linear\nhistories for a single file would be more complex to handle, too. And\npublishing just the history of one file would be damn complex.\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93782","messageId":"fcaeb9bf0810230651j1c02de13j61238c97661c32e9@mail.gmail.com","threadId":"16019","inReplyTo":"cb7bb73a0810230633r9970a50mbb4ecf3a855c3a21@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-10-23T13:51:53Z","receivedAt":"2008-10-23T13:51:53Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/23/08, Giuseppe Bilotta wrote:\n> On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy wrote:\n> > On 10/23/08, Giuseppe Bilotta wrote:\n> >> The principle is extremely simple: when you choose to start tracking a\n> >> file with Zit,\n> >>\n> >> zit track file\n> >>\n> >> Zit will create a directory .zit.file to hold a git repository\n> >> tracking the single file .zit.file/file, which is just a hard link to\n> >> file.\n> >\n> > Why not use one .zit repo and track each file on each own branch?.\n>\n>\n> So your proposal is to have a single .zit repo which is actually a git\n> repo and where each additional tracked file becomes its own branch,\n> and zit would take care of switching from branch to branch when zit\n> commands are called?\n\nI don't know if switching is necessary. With one file per pranch, the\nindex is even not necessary.\n\n> I think this solution would have a number of problems, apart from\n> being generally quite messy. First of all, moving a file and its\n> history somewhere else means toying around with the history of a much\n> wider repo, whereas the current approach would mean just moving the\n> .zit.file dir together with the file (modulo hardlinks). Non-linear\n> histories for a single file would be more complex to handle, too. And\n> publishing just the history of one file would be damn complex.\n\nThe history should be linear. Git (or zit) repository is just a\ncontainer for git branches. Each branch contains only one file. Moving\na file history is equivalent to \"git push\" + \"git branch -D\".\nSomething like this (not tested):\n\ncd dst\ngit init\ncd src\ngit push dst local-branch:remote-branch\ngit branch -D local-branch\ngit gc\n\n> --\n> Giuseppe \"Oblomov\" Bilotta\n>\n\n\n-- \nDuy\n"},{"id":"93786","messageId":"cb7bb73a0810230721o755182dfg10270e4a84208786@mail.gmail.com","threadId":"16019","inReplyTo":"fcaeb9bf0810230651j1c02de13j61238c97661c32e9@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-23T14:21:34Z","receivedAt":"2008-10-23T14:21:34Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Thu, Oct 23, 2008 at 3:51 PM, Nguyen Thai Ngoc Duy wrote:\n> On 10/23/08, Giuseppe Bilotta wrote:\n>> On Thu, Oct 23, 2008 at 2:50 PM, Nguyen Thai Ngoc Duy wrote:\n>> > On 10/23/08, Giuseppe Bilotta wrote:\n>> >> The principle is extremely simple: when you choose to start tracking a\n>> >> file with Zit,\n>> >>\n>> >> zit track file\n>> >>\n>> >> Zit will create a directory .zit.file to hold a git repository\n>> >> tracking the single file .zit.file/file, which is just a hard link to\n>> >> file.\n>> >\n>> > Why not use one .zit repo and track each file on each own branch?.\n>>\n>>\n>> So your proposal is to have a single .zit repo which is actually a git\n>> repo and where each additional tracked file becomes its own branch,\n>> and zit would take care of switching from branch to branch when zit\n>> commands are called?\n>\n> I don't know if switching is necessary. With one file per pranch, the\n> index is even not necessary.\n\n[...]\n\n> The history should be linear. Git (or zit) repository is just a\n> container for git branches. Each branch contains only one file. Moving\n> a file history is equivalent to \"git push\" + \"git branch -D\".\n> Something like this (not tested):\n>\n> cd dst\n> git init\n> cd src\n> git push dst local-branch:remote-branch\n> git branch -D local-branch\n> git gc\n\nLooks a little too clumsy for my taste. Also, I don't like the idea of\nhaving to enforce linear history for files, or getting rid of the\nindex. I would like zit to be as lightweight a wrapper for git as\npossible, retaining the whole functionality.\n\n\n\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93794","messageId":"gdqbta$rhe$1@ger.gmane.org","threadId":"16019","inReplyTo":"gdok16$vh2$1@ger.gmane.org","subject":"[RFC] Zit (v2): the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-23T17:22:48Z","receivedAt":"2008-10-23T17:22:48Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"I decided to give the simpler GIT_DIR approach another go.\n\nThe reworked Zit ( git://git.oblomov.eu/zit ) works by creating\n.file.git/ to track file's history. .file.git/info/excludes is\ninitialized to the very strong '*' pattern to ensure that things such\nas git status etc only consider the actually tracked file.\n\nThe obvious advantage over the previous implementation is that we\ndon't rely on fragile and non-portable hardlinks. The disadvantage\nis that something really bad can happen if a command fails to obey\nGIT_DIR or GIT_WORK_TREE correctly.\n\nCommand delegation is made a little smarter:\n\nzit somecommand file [args...]\n\ngets delegated to\n\ngit somecommand [args...]\n\nwith GIT_DIR=.file.git and GIT_WORK_TREE=\"`pwd`\", which works\nsurprisingly well. To prevent stupid expressions such as zit add file\nfile or zit commit file file, add and commit put the filename back at\nthe end of the parameter list.\n\nCommands that seem to work correctly so far are init, add, log,\nstatus, diff, remote, push, pull, and even rebase -i.\n\nCommands that definitely need some work are rm (should it just remove\nthe .file.git/ dir?) and mv (hairy: we would need to rename .file.git\nto .newname.git too, but rollbacks are likely to break things).\n\nThe only new command introduced by zit is zit list, which lists all\nzit-tracked files in the current directory, currently in a very\nbraindead way (e.g. I'd like it to display the proper status, such as\nC M or whatever; suggestions welcome).\n\nOn the TODO list is also some smart way to guess which file we're\ntalking about when no file is specified. Basically, the idea is to\ncheck if there's only one tracked file, or only one changed tracked\nfile, and allow a missing file option in that case.\n\nAs usual, comments suggestions and critiques welcome.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93811","messageId":"4901077A.7050904@gmx.ch","threadId":"16019","inReplyTo":"gdok16$vh2$1@ger.gmane.org","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Jean-Luc Herren","fromEmail":"jlh@gmx.ch","sentAt":"2008-10-23T23:23:38Z","receivedAt":"2008-10-23T23:23:38Z","isPatch":false,"sender":{"key":"jlh@gmx.ch","avatar":null},"body":"Hi!\n\nGiuseppe Bilotta wrote:\n> So today I decided to start hacking at a git-based but file-oriented\n> content tracker, which I decided to name Zit.\n\nThis sounds great and would seem very useful to manage my ~/bin/\ndirectory which contains a set of unrelated one-file-tools that\nevolve over time. I haven't played with it yet though.\n\n> when you choose to start tracking a file with Zit [...]\n> Zit will create a directory .zit.file to hold a git repository\n\nIf you have many files you want to track in a single directory\n(like ~/bin/), all those additional directories will quickly feel\nlike clutter. If you track every file, it will even double the\nnumber of things you see with an \"ls -a\".\n\nIf you decide against a shared repository, maybe you want to\nconsider to not use \".zit.file/\", but \".zit/file/\" as the\nrepository? This would reduce the clutter to a single directory,\njust like with \".git\". And moving files around wouldn't be that\nmuch complicated.\n\njlh\n"},{"id":"93828","messageId":"alpine.DEB.1.10.0810232314490.20238@asgard.lang.hm","threadId":"16019","inReplyTo":"gdqbta$rhe$1@ger.gmane.org","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-24T06:21:02Z","receivedAt":"2008-10-24T06:21:02Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 23 Oct 2008, Giuseppe Bilotta wrote:\n\n> I decided to give the simpler GIT_DIR approach another go.\n>\n> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating\n> .file.git/ to track file's history. .file.git/info/excludes is\n> initialized to the very strong '*' pattern to ensure that things such\n> as git status etc only consider the actually tracked file.\n>\n> The obvious advantage over the previous implementation is that we\n> don't rely on fragile and non-portable hardlinks. The disadvantage\n> is that something really bad can happen if a command fails to obey\n> GIT_DIR or GIT_WORK_TREE correctly.\n\nthis is a very interesting approach.\n\nthe thought that hit me as I finidhed reading this thread is that we \nare very close to having the full continum of file/repository combinations\n\n1. everything in the dir is part of one repository (the normal git case)\n\n2. some of all of the individual files in a dir is it's own repository \n(the zit case)\n\n3. the in-between case where you can have multiple repositories that can \nhave multiple files in them.\n\nhow hard would it be to extend zit to support case #3?\n\noffhand I can see it complicating the task of figuing out which repository \nto use for a file, but what else?\n\nDavid Lang\n\n\n> Command delegation is made a little smarter:\n>\n> zit somecommand file [args...]\n>\n> gets delegated to\n>\n> git somecommand [args...]\n>\n> with GIT_DIR=.file.git and GIT_WORK_TREE=\"`pwd`\", which works\n> surprisingly well. To prevent stupid expressions such as zit add file\n> file or zit commit file file, add and commit put the filename back at\n> the end of the parameter list.\n>\n> Commands that seem to work correctly so far are init, add, log,\n> status, diff, remote, push, pull, and even rebase -i.\n>\n> Commands that definitely need some work are rm (should it just remove\n> the .file.git/ dir?) and mv (hairy: we would need to rename .file.git\n> to .newname.git too, but rollbacks are likely to break things).\n>\n> The only new command introduced by zit is zit list, which lists all\n> zit-tracked files in the current directory, currently in a very\n> braindead way (e.g. I'd like it to display the proper status, such as\n> C M or whatever; suggestions welcome).\n>\n> On the TODO list is also some smart way to guess which file we're\n> talking about when no file is specified. Basically, the idea is to\n> check if there's only one tracked file, or only one changed tracked\n> file, and allow a missing file option in that case.\n>\n> As usual, comments suggestions and critiques welcome.\n>\n>\n"},{"id":"93829","messageId":"cb7bb73a0810232355u6de0479cyc260c80227f44e59@mail.gmail.com","threadId":"16019","inReplyTo":"4901077A.7050904@gmx.ch","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T06:55:55Z","receivedAt":"2008-10-24T06:55:55Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren wrote:\n> Hi!\n>\n> Giuseppe Bilotta wrote:\n>> So today I decided to start hacking at a git-based but file-oriented\n>> content tracker, which I decided to name Zit.\n>\n> This sounds great and would seem very useful to manage my ~/bin/\n> directory which contains a set of unrelated one-file-tools that\n> evolve over time. I haven't played with it yet though.\n\nNice to see I wasn't the only one with such a need 8-)\n\n>> when you choose to start tracking a file with Zit [...]\n>> Zit will create a directory .zit.file to hold a git repository\n>\n> If you have many files you want to track in a single directory\n> (like ~/bin/), all those additional directories will quickly feel\n> like clutter. If you track every file, it will even double the\n> number of things you see with an \"ls -a\".\n\nAh, good point, I hadn't thought about that.\n\n> If you decide against a shared repository, maybe you want to\n> consider to not use \".zit.file/\", but \".zit/file/\" as the\n> repository? This would reduce the clutter to a single directory,\n> just like with \".git\". And moving files around wouldn't be that\n> much complicated.\n\nRight. I'll give that a shot.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93832","messageId":"cb7bb73a0810240014o2209194dodc4a6fe3b754b04f@mail.gmail.com","threadId":"16019","inReplyTo":"alpine.DEB.1.10.0810232314490.20238@asgard.lang.hm","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T07:14:26Z","receivedAt":"2008-10-24T07:14:26Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 8:21 AM, wrote:\n> On Thu, 23 Oct 2008, Giuseppe Bilotta wrote:\n>\n>> I decided to give the simpler GIT_DIR approach another go.\n>>\n>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating\n>> .file.git/ to track file's history. .file.git/info/excludes is\n>> initialized to the very strong '*' pattern to ensure that things such\n>> as git status etc only consider the actually tracked file.\n>>\n>> The obvious advantage over the previous implementation is that we\n>> don't rely on fragile and non-portable hardlinks. The disadvantage\n>> is that something really bad can happen if a command fails to obey\n>> GIT_DIR or GIT_WORK_TREE correctly.\n>\n> this is a very interesting approach.\n>\n> the thought that hit me as I finidhed reading this thread is that we are\n> very close to having the full continum of file/repository combinations\n>\n> 1. everything in the dir is part of one repository (the normal git case)\n>\n> 2. some of all of the individual files in a dir is it's own repository (the\n> zit case)\n>\n> 3. the in-between case where you can have multiple repositories that can\n> have multiple files in them.\n>\n> how hard would it be to extend zit to support case #3?\n>\n> offhand I can see it complicating the task of figuring out which repository\n> to use for a file, but what else?\n\nI haven't tried this yet, but I think it should be possible without\nmuch problems. The important thing to keep in mind is that the second\nparameter to zit (for all commands but zit init) 'only' identifies the\nrepository, and the filename parameter is NOT passed to git. The only\nexceptions are zit add and git commit, and I'm having second thoughts\non add. Anyway, you can always use the 'raw' version of a command to\nguarantee that only GIT_DIR and GIT_WORK_TREE are set, thus:\n\n$ zit rawadd somefile -f someotherfile\n\nwill force-add someotherfile to somefile's repo. (Force adding is\nrequired because of the blanket exclude.) Of course, it would be\ninteresting adding to zit the capability to do\n\n$ zit diff someotherfile\n\nto make it guess that it should use somefile's repo. This is possible\nwith some symlinks for the git repos, probably.\n\nI'll have a look into it.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93841","messageId":"m38wsei8ne.fsf@localhost.localdomain","threadId":"16019","inReplyTo":"cb7bb73a0810232355u6de0479cyc260c80227f44e59@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-24T10:31:17Z","receivedAt":"2008-10-24T10:31:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Giuseppe Bilotta\" writes:\n> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren wrote:\n\n> > If you decide against a shared repository, maybe you want to\n> > consider to not use \".zit.file/\", but \".zit/file/\" as the\n> > repository? This would reduce the clutter to a single directory,\n> > just like with \".git\". And moving files around wouldn't be that\n> > much complicated.\n> \n> Right. I'll give that a shot.\n\nBy the way RCS which I use for version control of single files use\nboth approaches: it can store 'file,v' alongside 'file' (just like\nyour '.zit.file/' or '.file.git/'), but it can also store files on\nper-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or\n'.zit/file.git/' solution)\n\nBy the way, it would be nice to have VC interface for Emacs for Zit...\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"93842","messageId":"m34p32i83f.fsf@localhost.localdomain","threadId":"16019","inReplyTo":"gdqbta$rhe$1@ger.gmane.org","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-24T10:43:15Z","receivedAt":"2008-10-24T10:43:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Giuseppe Bilotta writes:\n\n> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating\n> .file.git/ to track file's history. .file.git/info/excludes is\n> initialized to the very strong '*' pattern to ensure that things such\n> as git status etc only consider the actually tracked file.\n[...]\n\nCould you add it to Git Wiki page:\n http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n\nI think that the project is interesting enough to be added there\neven if it is still in beta, or even alpha, stage.\n\n\nP.S. Currently I cannot access git.or.cz for some reason (it is\nup for everyone else, and even for me on different remote machine).\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"93843","messageId":"cb7bb73a0810240352u28bab2b5p907065680985270a@mail.gmail.com","threadId":"16019","inReplyTo":"m38wsei8ne.fsf@localhost.localdomain","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T10:52:35Z","receivedAt":"2008-10-24T10:52:35Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski wrote:\n> \"Giuseppe Bilotta\" writes:\n>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren wrote:\n>\n>> > If you decide against a shared repository, maybe you want to\n>> > consider to not use \".zit.file/\", but \".zit/file/\" as the\n>> > repository? This would reduce the clutter to a single directory,\n>> > just like with \".git\". And moving files around wouldn't be that\n>> > much complicated.\n>>\n>> Right. I'll give that a shot.\n>\n> By the way RCS which I use for version control of single files use\n> both approaches: it can store 'file,v' alongside 'file' (just like\n> your '.zit.file/' or '.file.git/'), but it can also store files on\n> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or\n> '.zit/file.git/' solution)\n\nIndeed, there's not particular reason why both solutions shouldn't be\navailable. I'll think about implementing it this way:\n\n$ zit init\n\nwill indicate that we want to track many files, and thus it will\ncreate a .zit directory under which RCS files will be available.\n\n$ zit track somefile\n\nwill start tracking somefile by setting up .zit/somefile.git if .zit\nis available or .somefile.git otherwise.\n\nThe only problem then is priority. When looking for a file's repo, do\nwe look at .file.git first, or .zit/file.git? How does RCS behave in\nthis case?\n\n> By the way, it would be nice to have VC interface for Emacs for Zit...\n\nI'm afraid someone else will have to take care of that, since Emacs is\nnot really something I use.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93844","messageId":"cb7bb73a0810240401q57e40b9dj46c35f90681cfa3d@mail.gmail.com","threadId":"16019","inReplyTo":"m34p32i83f.fsf@localhost.localdomain","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T11:01:48Z","receivedAt":"2008-10-24T11:01:48Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski wrote:\n> Giuseppe Bilotta writes:\n>\n>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating\n>> .file.git/ to track file's history. .file.git/info/excludes is\n>> initialized to the very strong '*' pattern to ensure that things such\n>> as git status etc only consider the actually tracked file.\n> [...]\n>\n> Could you add it to Git Wiki page:\n> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n>\n> I think that the project is interesting enough to be added there\n> even if it is still in beta, or even alpha, stage.\n\nAh, good idea. Done, in Version Control Interface layers section\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93845","messageId":"200810241332.32487.jnareb@gmail.com","threadId":"16019","inReplyTo":"cb7bb73a0810240352u28bab2b5p907065680985270a@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-24T11:32:23Z","receivedAt":"2008-10-24T11:32:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski wrote:\n>> \"Giuseppe Bilotta\" writes:\n>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren wrote:\n\n>>>> If you decide against a shared repository, maybe you want to\n>>>> consider to not use \".zit.file/\", but \".zit/file/\" as the\n>>>> repository? This would reduce the clutter to a single directory,\n>>>> just like with \".git\". And moving files around wouldn't be that\n>>>> much complicated.\n>>>\n>>> Right. I'll give that a shot.\n>>\n>> By the way RCS which I use for version control of single files use\n>> both approaches: it can store 'file,v' alongside 'file' (just like\n>> your '.zit.file/' or '.file.git/'), but it can also store files on\n>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or\n>> '.zit/file.git/' solution)\n> \n> Indeed, there's not particular reason why both solutions shouldn't be\n> available. [...]\n\n> The only problem then is priority. When looking for a file's repo, do\n> we look at .file.git first, or .zit/file.git? How does RCS behave in\n> this case?\n\nrcsintro(1) states:\n\n If you don't want to clutter your working directory with RCS files, create\n a subdirectory called RCS in your working directory, and move all your RCS\n files there. RCS commands will look *first* into that directory to find\n needed files.\n\n>> By the way, it would be nice to have VC interface for Emacs for Zit...\n> \n> I'm afraid someone else will have to take care of that, since Emacs is\n> not really something I use.\n\nI'll try to hack it using contrib/emacs/vc-git.el as a base...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"93846","messageId":"cb7bb73a0810240515x4d57ea03w1b245f83d740ddfd@mail.gmail.com","threadId":"16019","inReplyTo":"200810241332.32487.jnareb@gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T12:15:26Z","receivedAt":"2008-10-24T12:15:26Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 1:32 PM, Jakub Narebski wrote:\n> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n>> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski wrote:\n>>> By the way RCS which I use for version control of single files use\n>>> both approaches: it can store 'file,v' alongside 'file' (just like\n>>> your '.zit.file/' or '.file.git/'), but it can also store files on\n>>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or\n>>> '.zit/file.git/' solution)\n>>\n>> Indeed, there's not particular reason why both solutions shouldn't be\n>> available. [...]\n>\n>> The only problem then is priority. When looking for a file's repo, do\n>> we look at .file.git first, or .zit/file.git? How does RCS behave in\n>> this case?\n>\n> rcsintro(1) states:\n>\n> If you don't want to clutter your working directory with RCS files, create\n> a subdirectory called RCS in your working directory, and move all your RCS\n> files there. RCS commands will look *first* into that directory to find\n> needed files.\n\nCool. I pushed changes to this end to git.oblomov.eu/zit --now zit\nwill look for .zit/file.git first, then for .file.git; if neither is\nfound, and .zit/ exists, the repo is set to .zit/file.git, otherwise\nit's set to .file.git\n\nYou can either manually mkdir .zit, or use zit init that does exactly\nthe same thing.\n\n>>> By the way, it would be nice to have VC interface for Emacs for Zit...\n>>\n>> I'm afraid someone else will have to take care of that, since Emacs is\n>> not really something I use.\n>\n> I'll try to hack it using contrib/emacs/vc-git.el as a base...\n\nCool, thanks.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93861","messageId":"alpine.DEB.1.00.0810241943470.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"16019","inReplyTo":"49007623.1060606@viscovery.net","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-24T17:44:08Z","receivedAt":"2008-10-24T17:44:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 23 Oct 2008, Johannes Sixt wrote:\n\n> Giuseppe Bilotta schrieb:\n> > Zit will create a directory .zit.file to hold a git repository \n> > tracking the single file .zit.file/file, which is just a hard link to \n> > file.\n> \n> git breaks hard links, mind you! (Just in case you check out older \n> versions and you wonder why your \"real\" file is not updated).\n> \n> But there's a recent patch by Dscho floating around that takes care of \n> the hard link case.\n\nYep, I still want to work on it; it breaks on one of Junio's machines.\n\nCiao,\nDscho\n"},{"id":"93863","messageId":"cb7bb73a0810241048x47481727s92c8a6f8d318e82a@mail.gmail.com","threadId":"16019","inReplyTo":"alpine.DEB.1.00.0810241943470.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T17:48:43Z","receivedAt":"2008-10-24T17:48:43Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 7:44 PM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Thu, 23 Oct 2008, Johannes Sixt wrote:\n>\n>> Giuseppe Bilotta schrieb:\n>> > Zit will create a directory .zit.file to hold a git repository\n>> > tracking the single file .zit.file/file, which is just a hard link to\n>> > file.\n>>\n>> git breaks hard links, mind you! (Just in case you check out older\n>> versions and you wonder why your \"real\" file is not updated).\n>>\n>> But there's a recent patch by Dscho floating around that takes care of\n>> the hard link case.\n>\n> Yep, I still want to work on it; it breaks on one of Junio's machines.\n\nWell, it's not needed by Zit anymore, but there was someone else\nasking about on the ml recently, too 8-)\n\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93866","messageId":"7vabct3l1e.fsf@gitster.siamese.dyndns.org","threadId":"16019","inReplyTo":"m38wsei8ne.fsf@localhost.localdomain","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-24T18:28:13Z","receivedAt":"2008-10-24T18:28:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> \"Giuseppe Bilotta\" writes:\n>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren wrote:\n>\n>> > If you decide against a shared repository, maybe you want to\n>> > consider to not use \".zit.file/\", but \".zit/file/\" as the\n>> > repository? This would reduce the clutter to a single directory,\n>> > just like with \".git\". And moving files around wouldn't be that\n>> > much complicated.\n>> \n>> Right. I'll give that a shot.\n>\n> By the way RCS which I use for version control of single files use\n> both approaches: it can store 'file,v' alongside 'file' (just like\n> your '.zit.file/' or '.file.git/'), but it can also store files on\n> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or\n> '.zit/file.git/' solution)\n\nI am not opposed to the wish to track a single file (but I have to say I\nam not personally in need for such a feature), but I have to wonder from\nthe technical point of view if one-repo-per-file is the right approach.\n\nRunning \"git init\" in an empty directory consumes about 100k of diskspace\non the machine I am typing this on, and you should be able to share most\nof them (except one 41-byte file that is the branch tip ref) when you\ntrack many files inside a single directory by using a single repository,\none branch per file (or \"one set of branches per file\") model.\n"},{"id":"93868","messageId":"alpine.DEB.1.10.0810241159290.27333@asgard.lang.hm","threadId":"16019","inReplyTo":"7vabct3l1e.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-24T19:11:35Z","receivedAt":"2008-10-24T19:11:35Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 24 Oct 2008, Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n>\n>> \"Giuseppe Bilotta\" writes:\n>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren wrote:\n>>\n>>>> If you decide against a shared repository, maybe you want to\n>>>> consider to not use \".zit.file/\", but \".zit/file/\" as the\n>>>> repository? This would reduce the clutter to a single directory,\n>>>> just like with \".git\". And moving files around wouldn't be that\n>>>> much complicated.\n>>>\n>>> Right. I'll give that a shot.\n>>\n>> By the way RCS which I use for version control of single files use\n>> both approaches: it can store 'file,v' alongside 'file' (just like\n>> your '.zit.file/' or '.file.git/'), but it can also store files on\n>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or\n>> '.zit/file.git/' solution)\n>\n> I am not opposed to the wish to track a single file (but I have to say I\n> am not personally in need for such a feature), but I have to wonder from\n> the technical point of view if one-repo-per-file is the right approach.\n>\n> Running \"git init\" in an empty directory consumes about 100k of diskspace\n> on the machine I am typing this on, and you should be able to share most\n> of them (except one 41-byte file that is the branch tip ref) when you\n> track many files inside a single directory by using a single repository,\n> one branch per file (or \"one set of branches per file\") model.\n\nthe reason to use seperate repos is to ease the work involved if you need \nto move that file (and it's repo) elsewhere.\n\nwith the git directory being under .zit, would it be possible to link the \nthings that are nessasary togeather?\n\nhmm, looking at this in more detail.\n\nabout 44K of diskspace is used by the .sample hook files, so those can be \nremoved\n\nthe remaining 56K is mostly directories eating up a disk block\n\nfind . -ls\n200367 4 drwxr-xr-x 7 dlang users 4096 Oct 24 12:00 .\n200368 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./refs\n200369 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./refs/heads\n200370 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./refs/tags\n200371 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./branches\n200372 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./hooks\n200373 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./info\n1798469 4 -rw-r--r-- 1 dlang users 240 Oct 24 12:00 ./info/exclude\n1600716 4 -rw-r--r-- 1 dlang users 58 Oct 24 12:00 ./description\n200374 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./objects\n200375 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./objects/pack\n200376 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./objects/info\n1600717 4 -rw-r--r-- 1 dlang users 23 Oct 24 12:00 ./HEAD\n1600719 4 -rw-r--r-- 1 dlang users 92 Oct 24 12:00 ./config\n\nhow many of these are _really_ nessasary?\n\ntags, info, hooks, branches, and description could probably be skipped for \nthe common zit case, as long as they can be created as needed.\n\nIf git has problems with these not existing, would it make sense to make \ngit survive if they are missing and create them if needed?\n\nthe objects directory will eat up more space as revisions are checked in \n(and more sub-directories are created), would it make sense to have a \nconfig option to do a flat objects directory instead of the current \nfan-out?\n\nthe other option with objects would be to look into having a common \nobjects fan-out directory, but have the pack directory be per file. This \nwould allow you to seperate out one files stuff by creating packs for it \nand then grabbing everything in the per-file directory.\n\nthoughts?\n\nDavid Lang\n"},{"id":"93870","messageId":"cb7bb73a0810241242y7467f6fexcca4b7cd768e7992@mail.gmail.com","threadId":"16019","inReplyTo":"alpine.DEB.1.10.0810241159290.27333@asgard.lang.hm","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T19:42:09Z","receivedAt":"2008-10-24T19:42:09Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"I was slowly writing a reply but it seems David beat me to it, so here\ngoes a couple of additional comments.\n\nOn Fri, Oct 24, 2008 at 9:11 PM, wrote:\n> On Fri, 24 Oct 2008, Junio C Hamano wrote:\n>> Running \"git init\" in an empty directory consumes about 100k of diskspace\n>> on the machine I am typing this on, and you should be able to share most\n>> of them (except one 41-byte file that is the branch tip ref) when you\n>> track many files inside a single directory by using a single repository,\n>> one branch per file (or \"one set of branches per file\") model.\n>\n> the reason to use seperate repos is to ease the work involved if you need to\n> move that file (and it's repo) elsewhere.\n\nPrecisely. The one-repo-per-file is just the simplest and most\nflexible solution. But yes, I have to admit I hadn't looked into disk\nusage, and indeed we should try and squeeze this as much as possible.\n\n> with the git directory being under .zit, would it be possible to link the\n> things that are nessasary togeather?\n\nI'm not sure about _which_ files could be shared.\n\n> hmm, looking at this in more detail.\n>\n> about 44K of diskspace is used by the .sample hook files, so those can be\n> removed\n\nExactly. I'm setting up zit to prepare its repos to a more compact\nform, and getting rid of hooks and description is the first step.\n\n> the remaining 56K is mostly directories eating up a disk block\n>\n> find . -ls\n> 200367 4 drwxr-xr-x 7 dlang users 4096 Oct 24 12:00 .\n> 200368 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./refs\n> 200369 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n> ./refs/heads\n> 200370 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n> ./refs/tags\n> 200371 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n> ./branches\n> 200372 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./hooks\n> 200373 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./info\n> 1798469 4 -rw-r--r-- 1 dlang users 240 Oct 24 12:00\n> ./info/exclude\n> 1600716 4 -rw-r--r-- 1 dlang users 58 Oct 24 12:00\n> ./description\n> 200374 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./objects\n> 200375 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n> ./objects/pack\n> 200376 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n> ./objects/info\n> 1600717 4 -rw-r--r-- 1 dlang users 23 Oct 24 12:00 ./HEAD\n> 1600719 4 -rw-r--r-- 1 dlang users 92 Oct 24 12:00 ./config\n>\n> how many of these are _really_ nessasary?\n\nFor starters, I'm wondering if setting core.preferSymlinkRefs would be\nuseful here. Does it break sometihng?\n\n> tags, info, hooks, branches, and description could probably be skipped for\n> the common zit case, as long as they can be created as needed.\n\nIt seems that tags, hooks, branches and description can be done with.\n\ninfo contains exclude which is rather essential, and this is something\nthat could be shared across repositories. Also, we could spare a block\nby removing info, moving exclude to the .git dir and setting\ncore.excludesfile appropriately\n\n> the objects directory will eat up more space as revisions are checked in\n> (and more sub-directories are created), would it make sense to have a config\n> option to do a flat objects directory instead of the current fan-out?\n\nThis is probably the biggest remaining spacewaste. Typical zit usage\nwill generate a rather small number of objects, so flattening the\nobject store for the repo wouldn't be a bad idea. Is that possible?\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93872","messageId":"alpine.DEB.1.10.0810241244170.27333@asgard.lang.hm","threadId":"16019","inReplyTo":"cb7bb73a0810241242y7467f6fexcca4b7cd768e7992@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-24T19:46:06Z","receivedAt":"2008-10-24T19:46:06Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n\n> I was slowly writing a reply but it seems David beat me to it, so here\n> goes a couple of additional comments.\n>\n> On Fri, Oct 24, 2008 at 9:11 PM, wrote:\n>> On Fri, 24 Oct 2008, Junio C Hamano wrote:\n>>> Running \"git init\" in an empty directory consumes about 100k of diskspace\n>>> on the machine I am typing this on, and you should be able to share most\n>>> of them (except one 41-byte file that is the branch tip ref) when you\n>>> track many files inside a single directory by using a single repository,\n>>> one branch per file (or \"one set of branches per file\") model.\n>>\n>> the reason to use seperate repos is to ease the work involved if you need to\n>> move that file (and it's repo) elsewhere.\n>\n> Precisely. The one-repo-per-file is just the simplest and most\n> flexible solution. But yes, I have to admit I hadn't looked into disk\n> usage, and indeed we should try and squeeze this as much as possible.\n>\n>> with the git directory being under .zit, would it be possible to link the\n>> things that are nessasary togeather?\n>\n> I'm not sure about _which_ files could be shared.\n>\n>> hmm, looking at this in more detail.\n>>\n>> about 44K of diskspace is used by the .sample hook files, so those can be\n>> removed\n>\n> Exactly. I'm setting up zit to prepare its repos to a more compact\n> form, and getting rid of hooks and description is the first step.\n>\n>> the remaining 56K is mostly directories eating up a disk block\n>>\n>> find . -ls\n>> 200367 4 drwxr-xr-x 7 dlang users 4096 Oct 24 12:00 .\n>> 200368 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./refs\n>> 200369 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n>> ./refs/heads\n>> 200370 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n>> ./refs/tags\n>> 200371 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n>> ./branches\n>> 200372 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./hooks\n>> 200373 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00 ./info\n>> 1798469 4 -rw-r--r-- 1 dlang users 240 Oct 24 12:00\n>> ./info/exclude\n>> 1600716 4 -rw-r--r-- 1 dlang users 58 Oct 24 12:00\n>> ./description\n>> 200374 4 drwxr-xr-x 4 dlang users 4096 Oct 24 12:00 ./objects\n>> 200375 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n>> ./objects/pack\n>> 200376 4 drwxr-xr-x 2 dlang users 4096 Oct 24 12:00\n>> ./objects/info\n>> 1600717 4 -rw-r--r-- 1 dlang users 23 Oct 24 12:00 ./HEAD\n>> 1600719 4 -rw-r--r-- 1 dlang users 92 Oct 24 12:00 ./config\n>>\n>> how many of these are _really_ nessasary?\n>\n> For starters, I'm wondering if setting core.preferSymlinkRefs would be\n> useful here. Does it break sometihng?\n>\n>> tags, info, hooks, branches, and description could probably be skipped for\n>> the common zit case, as long as they can be created as needed.\n>\n> It seems that tags, hooks, branches and description can be done with.\n\ndo you mean 'can be done away with'?\n\n> info contains exclude which is rather essential,\n\nis it? by default everything in this file is commented out. And with you \nonly adding files explicitly why would it ever need to excluded anything?\n\nDavid Lang\n"},{"id":"93873","messageId":"cb7bb73a0810241251w4c2486a0x4684a25b364ebbbb@mail.gmail.com","threadId":"16019","inReplyTo":"alpine.DEB.1.10.0810241244170.27333@asgard.lang.hm","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T19:51:29Z","receivedAt":"2008-10-24T19:51:29Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 9:46 PM, wrote:\n> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n>>\n>> It seems that tags, hooks, branches and description can be done with.\n>\n> do you mean 'can be done away with'?\n\nAhem. Yes. I've got a patch ready for zit that gets rid of them.\n\n(A smarter way would be to create a template, but I'm not smart.)\n\n>> info contains exclude which is rather essential,\n>\n> is it? by default everything in this file is commented out. And with you\n> only adding files explicitly why would it ever need to excluded anything?\n\nZit does\n \t\techo \"*\" > $GIT_DIR/info/exclude\nand yes it sucks to use a whole block for a file that only contains\none character. Suggestions welcome.\n\nThe reason why we want the exclude is that when you do zit status\nsomefile you don't want every other file in the directory to come up\nas 'not tracked'.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93874","messageId":"alpine.DEB.1.10.0810241251490.27333@asgard.lang.hm","threadId":"16019","inReplyTo":"7vabct3l1e.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-24T19:53:21Z","receivedAt":"2008-10-24T19:53:21Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 24 Oct 2008, Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n>\n>> \"Giuseppe Bilotta\" writes:\n>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren wrote:\n>>\n>>>> If you decide against a shared repository, maybe you want to\n>>>> consider to not use \".zit.file/\", but \".zit/file/\" as the\n>>>> repository? This would reduce the clutter to a single directory,\n>>>> just like with \".git\". And moving files around wouldn't be that\n>>>> much complicated.\n>>>\n>>> Right. I'll give that a shot.\n>>\n>> By the way RCS which I use for version control of single files use\n>> both approaches: it can store 'file,v' alongside 'file' (just like\n>> your '.zit.file/' or '.file.git/'), but it can also store files on\n>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or\n>> '.zit/file.git/' solution)\n>\n> I am not opposed to the wish to track a single file (but I have to say I\n> am not personally in need for such a feature), but I have to wonder from\n> the technical point of view if one-repo-per-file is the right approach.\n\nI just had what's probably a silly thought.\n\nhow close is a zit setup to a subproject setup?\n\nDavid Lang\n"},{"id":"93875","messageId":"alpine.DEB.1.10.0810241254330.27333@asgard.lang.hm","threadId":"16019","inReplyTo":"cb7bb73a0810241251w4c2486a0x4684a25b364ebbbb@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-10-24T19:54:57Z","receivedAt":"2008-10-24T19:54:57Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n\n> On Fri, Oct 24, 2008 at 9:46 PM, wrote:\n>> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n>>>\n>>> It seems that tags, hooks, branches and description can be done with.\n>>\n>> do you mean 'can be done away with'?\n>\n> Ahem. Yes. I've got a patch ready for zit that gets rid of them.\n>\n> (A smarter way would be to create a template, but I'm not smart.)\n>\n>>> info contains exclude which is rather essential,\n>>\n>> is it? by default everything in this file is commented out. And with you\n>> only adding files explicitly why would it ever need to excluded anything?\n>\n> Zit does\n> \t\techo \"*\" > $GIT_DIR/info/exclude\n> and yes it sucks to use a whole block for a file that only contains\n> one character. Suggestions welcome.\n\ncan this be configured in the config file?\n\n> The reason why we want the exclude is that when you do zit status\n> somefile you don't want every other file in the directory to come up\n> as 'not tracked'.\n\ngood point.\n\nDavid Lang\n"},{"id":"93877","messageId":"cb7bb73a0810241306i78078298o9483f8f93c238ac2@mail.gmail.com","threadId":"16019","inReplyTo":"alpine.DEB.1.10.0810241251490.27333@asgard.lang.hm","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T20:06:44Z","receivedAt":"2008-10-24T20:06:44Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 9:53 PM, wrote:\n> I just had what's probably a silly thought.\n>\n> how close is a zit setup to a subproject setup?\n\nHonestly, I haven't the slightest idea how they work. My\nunderstanding, which could be completely wrong, is that they are\nfull-fledged git repositories, and that additional metadata at the top\nlevel takes care of understanding what ref is needed for each toplevel\nproject. If this is true, using them wouldn't simplify zit, but rather\nmake it more complex (and space intensive).\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93879","messageId":"cb7bb73a0810241313o341febccgbea1cd59b25b9cc4@mail.gmail.com","threadId":"16019","inReplyTo":"alpine.DEB.1.10.0810241254330.27333@asgard.lang.hm","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-24T20:13:31Z","receivedAt":"2008-10-24T20:13:31Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 9:54 PM, wrote:\n> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n>> Zit does\n>> echo \"*\" > $GIT_DIR/info/exclude\n>> and yes it sucks to use a whole block for a file that only contains\n>> one character. Suggestions welcome.\n>\n> can this be configured in the config file?\n\nYes, the file pointed at by the config key core.excludesfile is read\ntoo, so we could have it point at $GIT_DIR/zitexclude, which would\nallow us to spare a block. The most space saving would be achieved by\na core.excludepattern or similar key, which would allow us to get rid\nof the exclude file altogether.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93880","messageId":"200810242230.49238.jnareb@gmail.com","threadId":"16019","inReplyTo":"cb7bb73a0810241313o341febccgbea1cd59b25b9cc4@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-24T20:30:47Z","receivedAt":"2008-10-24T20:30:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n> On Fri, Oct 24, 2008 at 9:54 PM, wrote:\n>> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:\n>>> Zit does\n>>> echo \"*\" > $GIT_DIR/info/exclude\n>>> and yes it sucks to use a whole block for a file that only contains\n>>> one character. Suggestions welcome.\n>>\n>> can this be configured in the config file?\n> \n> Yes, the file pointed at by the config key core.excludesfile is read\n> too, so we could have it point at $GIT_DIR/zitexclude, which would\n> allow us to spare a block. The most space saving would be achieved by\n> a core.excludepattern or similar key, which would allow us to get rid\n> of the exclude file altogether.\n\nWell, with all zit repositories in '.zit/' directory (similar to RCS/)\nyou could have point core.excludesfile to _common_ '.zit/excludes';\nthe pattern doesn't change from zit repository to zit repository?\n\nYou could even use per-user ~/.zitignore (I'm not sure if git expands \n'~' in paths; there was some patch for it, but was it accepted?) or \nsystem-wide /usr/lib/zitignore or /usr/libexec/zitignore file.\n-- \nJakub Narebski\nPoland\n"},{"id":"93914","messageId":"cb7bb73a0810250048q7ad8595bt565de05ec2ec37cb@mail.gmail.com","threadId":"16019","inReplyTo":"200810242230.49238.jnareb@gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-25T07:48:24Z","receivedAt":"2008-10-25T07:48:24Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Oct 24, 2008 at 10:30 PM, Jakub Narebski wrote:\n> Well, with all zit repositories in '.zit/' directory (similar to RCS/)\n> you could have point core.excludesfile to _common_ '.zit/excludes';\n> the pattern doesn't change from zit repository to zit repository?\n>\n> You could even use per-user ~/.zitignore (I'm not sure if git expands\n> '~' in paths; there was some patch for it, but was it accepted?) or\n> system-wide /usr/lib/zitignore or /usr/libexec/zitignore file.\n\nSystem-wide means maximum space save, but it require system\nadministration to install Zit, and considering that one of the things\nI love of Zit now is its being self contained, I would rather not\ndepend on anything system-wide anyway.\n\nThe user .zitignore file is probably the best approach: we can create\nit ourselves (usually), and even if Git doesn't expand the pathname\nitself, we can just use an absolute path. I'll go that way.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93915","messageId":"200810251110.25704.jnareb@gmail.com","threadId":"16019","inReplyTo":"cb7bb73a0810250048q7ad8595bt565de05ec2ec37cb@mail.gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-25T09:10:24Z","receivedAt":"2008-10-25T09:10:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 25 Oct 2008, Giuseppe Bilotta wrote:\n> On Fri, Oct 24, 2008 at 10:30 PM, Jakub Narebski wrote:\n> > Well, with all zit repositories in '.zit/' directory (similar to RCS/)\n> > you could have point core.excludesfile to _common_ '.zit/excludes';\n> > the pattern doesn't change from zit repository to zit repository?\n> >\n> > You could even use per-user ~/.zitignore (I'm not sure if git expands\n> > '~' in paths; there was some patch for it, but was it accepted?) [...]\n[...]\n \n> The user .zitignore file is probably the best approach: we can create\n> it ourselves (usually), and even if Git doesn't expand the pathname\n> itself, we can just use an absolute path. I'll go that way.\n\nFirst, absolute path to ~/.zitignore is a bit fragile: what if layout\nof home directories for users change, for example because of increasing\nnumber of users some fan-out is required (/home/nick -> /home/2/nick)?\nSecond, ~/.zitignore looks like something that user can change; if\nyou install zit, it can install libexec/zitignore somewhere... or just\nuse ./zit/excludes (with 'do not edit' comment perhaps...).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"93918","messageId":"cb7bb73a0810250330w39811a29g7b497ec70a3b9085@mail.gmail.com","threadId":"16019","inReplyTo":"200810251110.25704.jnareb@gmail.com","subject":"Re: [RFC] Zit: the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-25T10:30:40Z","receivedAt":"2008-10-25T10:30:40Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Sat, Oct 25, 2008 at 11:10 AM, Jakub Narebski wrote:\n> On Sat, 25 Oct 2008, Giuseppe Bilotta wrote:\n>\n>> The user .zitignore file is probably the best approach: we can create\n>> it ourselves (usually), and even if Git doesn't expand the pathname\n>> itself, we can just use an absolute path. I'll go that way.\n>\n> First, absolute path to ~/.zitignore is a bit fragile: what if layout\n> of home directories for users change, for example because of increasing\n> number of users some fan-out is required (/home/nick -> /home/2/nick)?\n> Second, ~/.zitignore looks like something that user can change; if\n> you install zit, it can install libexec/zitignore somewhere... or just\n> use ./zit/excludes (with 'do not edit' comment perhaps...).\n\n(Actually, I just found another interesting thing about the config, in\nthat it stores the path to the work tree. This is not a problem,\nthough, because zit_setup() sets GIT_WORK_TREE.)\n\nAs I said, I don't like depending on stuff that needs to be installed.\nFor example, what about user (non-system) installs? the libexec (or\nwhatever) solution would have the same problem as the ~/.zitignore\nsolution, with the moving $HOME.\n\nI guess this leaves the .zit/ solution as the most robust one,\nalthough it's not the most space-effective, especially if you have\nmany directories, each with a single tracked file. On the plus side,\ngoing for the .zit/ solution and dropping support for .somefile.git/\nmeans some significant code semplification.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"93983","messageId":"m3k5bvgz83.fsf@localhost.localdomain","threadId":"16019","inReplyTo":"cb7bb73a0810240401q57e40b9dj46c35f90681cfa3d@mail.gmail.com","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-26T15:20:17Z","receivedAt":"2008-10-26T15:20:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Giuseppe Bilotta\" writes:\n> On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski wrote:\n>> Giuseppe Bilotta writes:\n>>\n>>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating\n>>> .file.git/ to track file's history. .file.git/info/excludes is\n>>> initialized to the very strong '*' pattern to ensure that things such\n>>> as git status etc only consider the actually tracked file.\n>> [...]\n>>\n>> Could you add it to Git Wiki page:\n>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools\n>>\n>> I think that the project is interesting enough to be added there\n>> even if it is still in beta, or even alpha, stage.\n> \n> Ah, good idea. Done, in Version Control Interface layers section\n\nThanks.\n\nI have added link to repositoy, as you didn't configure your gitweb to\ndisplay those URL links (see gitweb/README and gitweb/INSTALL).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"93999","messageId":"cb7bb73a0810261418y3b114e2ag81cbb75c4a80603c@mail.gmail.com","threadId":"16019","inReplyTo":"m3k5bvgz83.fsf@localhost.localdomain","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-26T21:18:57Z","receivedAt":"2008-10-26T21:18:57Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski wrote:\n> \"Giuseppe Bilotta\" writes:\n>> Ah, good idea. Done, in Version Control Interface layers section\n>\n> Thanks.\n>\n> I have added link to repositoy, as you didn't configure your gitweb to\n> display those URL links (see gitweb/README and gitweb/INSTALL).\n\nOops, right, thanks. BTW, isn't there a way to have the git:// URL be\ncomputed automatically? Judging by the docs, it seems that I have to\nset it manually for each project, like the description.\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"94002","messageId":"200810262304.13582.jnareb@gmail.com","threadId":"16019","inReplyTo":"cb7bb73a0810261418y3b114e2ag81cbb75c4a80603c@mail.gmail.com","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-26T22:04:12Z","receivedAt":"2008-10-26T22:04:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Giuseppe Bilotta wrote:\n> On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski wrote:\n>> \"Giuseppe Bilotta\" writes:\n>>>\n>>> Ah, good idea. Done, in Version Control Interface layers section\n>>\n>> Thanks.\n>>\n>> I have added link to repositoy, as you didn't configure your gitweb to\n>> display those URL links (see gitweb/README and gitweb/INSTALL).\n> \n> Oops, right, thanks. BTW, isn't there a way to have the git:// URL be\n> computed automatically? Judging by the docs, it seems that I have to\n> set it manually for each project, like the description.\n\ngitweb/README:\n\n How to configure gitweb for your local system\n ---------------------------------------------\n [...]\n * GITWEB_BASE_URL\n Git base URLs used for URL to where fetch project from, i.e. full\n URL is \"$git_base_url/$project\". Shown on projects summary page.\n Repository URL for project can be also configured per repository; this\n takes precedence over URLs composed from base URL and a project name.\n Note that you can setup multiple base URLs (for example one for\n git:// protocol access, another for http:// access) from the gitweb\n config file. [No default]\n\n [...]\n Runtime gitweb configuration\n ----------------------------\n [...]\n Gitweb config file variables\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n [...]\n * @git_base_url_list\n List of git base URLs used for URL to where fetch project from, shown\n in project summary page. Full URL is \"$git_base_url/$project\".\n You can setup multiple base URLs (for example one for git:// protocol\n access, and one for http:// \"dumb\" protocol access). Note that per\n repository configuration in 'cloneurl' file, or as values of gitweb.url\n project config.\n\nOoops, there seems to be a type in above...\n\n Per-repository gitweb configuration\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n [...]\n * cloneurl (or multiple-valued gitweb.url)\n File with repository URL (used for clone and fetch), one per line.\n Displayed in the project summary page. You can use multiple-valued\n gitweb.url repository configuration variable for that, but the file\n takes precedence.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"94005","messageId":"cb7bb73a0810261516i32554afera3250e1b6a0f02b9@mail.gmail.com","threadId":"16019","inReplyTo":"200810262304.13582.jnareb@gmail.com","subject":"Re: [RFC] Zit (v2): the git-based single file content tracker","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-10-26T22:16:14Z","receivedAt":"2008-10-26T22:16:14Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Sun, Oct 26, 2008 at 11:04 PM, Jakub Narebski wrote:\n> Gitweb config file variables\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> [...]\n> * @git_base_url_list\n> List of git base URLs used for URL to where fetch project from, shown\n> in project summary page. Full URL is \"$git_base_url/$project\".\n> You can setup multiple base URLs (for example one for git:// protocol\n> access, and one for http:// \"dumb\" protocol access). Note that per\n> repository configuration in 'cloneurl' file, or as values of gitweb.url\n> project config.\n\nDoh, thanks, I had totally overlooked it. Done 8-)\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"}]}