{"thread":{"id":"1845","subject":"first impressions to git","startedAt":"2005-09-18T11:12:59Z","lastAt":"2005-09-19T19:14:28Z","messageCount":11,"participants":["Nico -telmich- Schottelius","Petr Baudis","Daniel Barkalow","Junio C Hamano","Kay Sievers","Linus Torvalds","Sven Verdoolaege"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8775","messageId":"20050918111259.GA10882@schottelius.org","threadId":"1845","inReplyTo":null,"subject":"first impressions to git","fromName":"Nico -telmich- Schottelius","fromEmail":"nico-linux-git@schottelius.org","sentAt":"2005-09-18T11:12:59Z","receivedAt":"2005-09-18T11:12:59Z","isPatch":false,"sender":{"key":"nico-linux-git@schottelius.org","avatar":null},"body":"Hello!\n\nI was testing git for my needs with the following ideas in my mind:\n\n- it must be easy to use\n- documentation must be easy to find, understand and remember\n- it should be fast\n- optionally using the filesystem as a database would be nice\n\nMy first impressions are:\n\n- many commands, reminds me of arch/tla\n- nice idea with .git\n- uses the filesystem\n- using git directly seems to be more work than necessary\n- cogito looks like a good frontend, but has some drawbacks\n- it's not clear which protocols for pull/push are supported\n- the documentation is not in sync with the programm (0.99.5 vs. 0.99.6)\n- gitweb.cgi could be better documentated and supported\n   recursive directories when using $projects_list = $projectroot;\n   and splitting configuration completly outside of gitweb.cgi would be nice\n   (having .gitweb in the same directory as gitweb.cgi for instance)\n- I am not able to upload cinit, because\n   o adding directories with files and files I want to exclude is not easily\n     possible\n\n   o it's not clear to me, how I should publish (push)\n      - scp/rsync from outside\n      - git/cogito push\n   o excluding *.o seems not to work, neither through .gitignore nor through\n     .git/info/exlude\n- How do I check integrity of files, is signed files somehow implemented?\n\nI've written some notes down in\n   http://creme.schottelius.org/~nico/temp/cogito\n   http://creme.schottelius.org/~nico/temp/git-erfahrungen\n\nAdding directories with git-script-add (or whatever) would be nice in the way\nit adds the contents of the directory recursively.\n\nThat's it for the first impression, I would be happy for any hints and critic\nif I did something 'really wrong' with git/cogito.\n\nMy current position to git/cogito is that using could be possible, but not\nas comfortable (from a developers view) as it is with monotone.\n\nSincerly,\n\nNico\n\nP.S.: These are mostly the negative things, I've to say that\n   o gitweb.cgi looks very beautiful\n   o git es very fast\n   o cogito could in fact be a nice frontend, after removing the current bugs\n     and if it has nicer error messaeges, which tell me WHAT I did wrong and\n     HOW to do it right.\n\n-- \nLatest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)\nOpen Source nutures open minds and free, creative developers.\n"},{"id":"8777","messageId":"20050918145434.GA22391@pasky.or.cz","threadId":"1845","inReplyTo":"20050918111259.GA10882@schottelius.org","subject":"Re: first impressions to git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-18T14:54:34Z","receivedAt":"2005-09-18T14:54:34Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Sep 18, 2005 at 01:12:59PM CEST, I got a letter\nwhere Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...\n> Hello!\n\nHello,\n\n> My first impressions are:\n> \n> - many commands, reminds me of arch/tla\n\nthis is one of Cogito's considerations, I try to keep the number of\ncommands low. It's 26 non-admin commands now, which might raise a bit\nyet, but hopefully not by much. And I was thinking about coupling stuff\nlike cg-branch-* to a single command.\n\n> - I am not able to upload cinit, because\n>    o adding directories with files and files I want to exclude is not easily\n>      possible\n\nJust fixed, cg-init should now DTRT.\n\n>    o it's not clear to me, how I should publish (push)\n>       - scp/rsync from outside\n>       - git/cogito push\n\nPush works fine for anything but the initial push - recursive scp or\nrsync of the whole repository is probably the easiest solution. It would\nbe nice if git-send-pack would support the initial push.\n\n>    o excluding *.o seems not to work, neither through .gitignore nor through\n>      .git/info/exlude\n\nIt should now work during the initial commit.\n\n> - How do I check integrity of files, is signed files somehow implemented?\n\nThis was discussed on IRC, it seems signed tags were the answer you\nwere looking for.\n\n> I've written some notes down in\n>    http://creme.schottelius.org/~nico/temp/cogito\n\nPretty much all of this solved now, I think.\n\n>    http://creme.schottelius.org/~nico/temp/git-erfahrungen\n> \n> Adding directories with git-script-add (or whatever) would be nice in the way\n> it adds the contents of the directory recursively.\n\ncg-add -r implemented now.\n\n>    o cogito could in fact be a nice frontend, after removing the current bugs\n>      and if it has nicer error messaeges, which tell me WHAT I did wrong and\n>      HOW to do it right.\n\nThis was one thing I kept in mind when making Cogito as well, I tried to\nmake its error messages as helpful as possible. It would be great if you\ncould point out where _Cogito_'s error messages might be more helpful\n(it's tougher with Git, but I'm sure they'll love to make their error\nmessages more helpful as well - one thing I _really_ don't want to get\ninto is filtering Git's error messages and rewriting them ;-).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"8781","messageId":"Pine.LNX.4.63.0509181201220.23242@iabervon.org","threadId":"1845","inReplyTo":"20050918111259.GA10882@schottelius.org","subject":"Re: first impressions to git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-09-18T16:56:21Z","receivedAt":"2005-09-18T16:56:21Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 18 Sep 2005, Nico -telmich- Schottelius wrote:\n\n> Hello!\n> \n> I was testing git for my needs with the following ideas in my mind:\n> \n> - it must be easy to use\n> - documentation must be easy to find, understand and remember\n> - it should be fast\n> - optionally using the filesystem as a database would be nice\n> \n> My first impressions are:\n> \n> - many commands, reminds me of arch/tla\n\ngit's got a lot of internal commands that you shouldn't need to use. If \nyou don't count the executables, but rather count the options listed by \n\"git\"... you still get a lot. But most of those are scripts for doing \ncommon operations. Maybe we should have a list of the set of commands you \nactually need, without the commands that are unnecessary but streamline \nthings you might want to do? (For example, git format-patch generates a \nset of patches in a single command with a single argument; but you can \nalso generate a diff with git diff, if you want the primitive operation.)\n\nI think the only ones you actually need are: init-db, add, commit, \ncheckout, push, pull, status, diff, log, and tag. But if you're trying to \ntrack down which commit broke something, bisect will come in handy. And \nthere's applymbox for applying an mbox file of patches, and so forth.\n\n>    o it's not clear to me, how I should publish (push)\n>       - scp/rsync from outside\n>       - git/cogito push\n\nYou generally want some public location which allows at least one of \nanonymous rsync, http, and git-daemon (e.g., kernel.org currently serves \nthe relevant directories by rsync and http). You then push to that \nlocation from wherever you actually work.\n\n>    o excluding *.o seems not to work, neither through .gitignore nor through\n>      .git/info/exlude\n> - How do I check integrity of files, is signed files somehow implemented?\n> \n> I've written some notes down in\n>    http://creme.schottelius.org/~nico/temp/git-erfahrungen\n\n(Now at .../git-erfahrungen01)\n\nIt looks like you managed to be using an *older* version than the \ndocumentation; git-update-index is the new name, not the old one. I'm not \nsure how that happened, but I'd guess a \"make install\" bug or a PATH issue \nor something.\n\nWe need to fix the error for trying to add a directory, and we should \nprobably support it in \"add\".\n\nCore git doesn't have a .git/info/excludes at all. (And, in general, \n.gitignore makes more sense, I think, because you usually want this to be \nversion-controlled; but maybe there should be .git/info/excludes as a \ndefault for new directories?)\n\n.git/description is actually a gitweb feature, not a core git feature. \nYou'd only set it up for public repositories that you want to describe.\n\nI'd be much obliged if you could tell me where the documentation lost you; \nit's really hard to document effectively without the assistance of someone \nwho doesn't already know the program.\n\n\".git/remotes\" is the current one; \".git/branches\" is obsolete.\n\nThe only \"push\" protocol is ssh (using an scp-style path). Pull protocols \nare: ssh (using the scp-style path), anonymous rsync, \nhttp/https/ftp/anything else \"curl\" supports, and the git daemon protocol \n(that is, you can run a program directly or from inetd to serve files to \nclients that ask with \"git://\" URLs).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"8788","messageId":"7vr7bm470m.fsf@assigned-by-dhcp.cox.net","threadId":"1845","inReplyTo":"Pine.LNX.4.63.0509181201220.23242@iabervon.org","subject":"Re: first impressions to git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T17:31:37Z","receivedAt":"2005-09-18T17:31:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> We need to fix the error for trying to add a directory, and we should \n> probably support it in \"add\".\n\nYup.\n\n> Core git doesn't have a .git/info/excludes at all. (And, in general, \n> .gitignore makes more sense, I think, because you usually want this to be \n> version-controlled; but maybe there should be .git/info/excludes as a \n> default for new directories?)\n\nWe by default install info/excludes disabled in a new repository\nand 'git status' looks at it.  What it _does_ not do is to use\nany exclude patterns by default; if info/excludes is empty\n(modulo '# comment' lines) it does not use .gitignore.\n\n> \".git/remotes\" is the current one; \".git/branches\" is obsolete.\n\nPerhaps deprecated but obsolete is too strong a word -- it still\nis supported.\n"},{"id":"8805","messageId":"20050918211855.GA1463@schottelius.org","threadId":"1845","inReplyTo":"Pine.LNX.4.63.0509181201220.23242@iabervon.org","subject":"Re: first impressions to git","fromName":"Nico -telmich- Schottelius","fromEmail":"nico-linux-git@schottelius.org","sentAt":"2005-09-18T21:18:56Z","receivedAt":"2005-09-18T21:18:56Z","isPatch":false,"sender":{"key":"nico-linux-git@schottelius.org","avatar":null},"body":"First of all, thanks for that many very good explaining answers.\n\nI'll try to answer all questions/suggestions in one mail\n(I hope your MUA supports threading when one e-mail has several In-Reply-Tos ;-),\nstill in respect to the good answers, ripping them out to make the mail short.\n\nAdrien Beau [Sun, Sep 18, 2005 at 04:33:05PM +0200]:\n> [fetch/send]\n\nGot to know the terminology, although every SCM/VCS has a different one :)\n\n> [...]\n> In that case, you can ask to transfer one or many refs. All the\n> objects that need transfering are packed and then sent. The transfer\n> can be local, over SSH, or over a custom Git protocol.\n\nMay I ask, how the git-protocol works or may you point me to a document\ndescribing it?\n\n> Note that there is a problem if a Git-unaware daemon is used on the\n> server (typical in the case of HTTP and rsync). If someone pulls while\n> a push is in progress, references to not-yet-uploaded objects can be\n> retrieved.\n\nWell, this will most likely happen often or how do you normally publish\nyour famous .git-directory?\n\n> > - the documentation is not in sync with the programm (0.99.5 vs. 0.99.6)\n> \n> Actually, the documentation is mostly in sync with the programs,\n> except for that version number. There's still room for improvements\n> though, patches welcome, or so I've heard.\n\n[22:29] hydrogenium:git-core-0.99.6% ls git-update-*\ngit-update-cache  git-update-server-info\n\nhttp://www.kernel.org/pub/software/scm/git/docs/tutorial.html (v0.99.5, Aug 2005):\n\n\"The first step is trivial: when you want to tell git about any changes to your working tree, you use the git-update-index program.\"\n\nPetr Baudis [Sun, Sep 18, 2005 at 04:54:34PM +0200]:\n> [many fixes]\n\nthanks for the fast response!\n\nDaniel Barkalow [Sun, Sep 18, 2005 at 12:56:21PM -0400]:\n> >    o excluding *.o seems not to work, neither through .gitignore nor through\n> >      .git/info/exlude\n> > - How do I check integrity of files, is signed files somehow implemented?\n> > \n> > I've written some notes down in\n> >    http://creme.schottelius.org/~nico/temp/git-erfahrungen\n> \n> (Now at .../git-erfahrungen01)\n\nSorry, yes, had to move it there, because I wanted to add new experiences\nto a new file. It's now 'linked'.\n\n> It looks like you managed to be using an *older* version than the \n> documentation; git-update-index is the new name, not the old one. I'm not \n> sure how that happened, but I'd guess a \"make install\" bug or a PATH issue \n> or something.\n\nSee above, if you need more information, tell me.\n\n> Core git doesn't have a .git/info/excludes at all. (And, in general, \n> .gitignore makes more sense, I think, because you usually want this to be \n> version-controlled; but maybe there should be .git/info/excludes as a \n> default for new directories?)\n\nSo, this is not really clear :)\n\n> .git/description is actually a gitweb feature, not a core git feature. \n> You'd only set it up for public repositories that you want to describe.\n\nThat does not fit to what I see here:\n\n[22:46] hydrogenium:gpm% git-init-db \ndefaulting to local storage area\n[22:46] hydrogenium:gpm% ls .git \nbranches  description  HEAD  hooks  info  objects  refs  remotes\n\n> I'd be much obliged if you could tell me where the documentation lost you; \n> it's really hard to document effectively without the assistance of someone \n> who doesn't already know the program.\n\nWell, my way was:\n\n- find git [http://www.kernel.org/pub/software/scm/git/]\n- find documentation [http://www.kernel.org/pub/software/scm/git/docs/]\n- find step-by-step doc\n   [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html]\n\nSo far so fine, than I found the git-update-index/cache thing, which confused\nme, I was not sure, whether this documentation fits only partly to git\nor absolutely not. Still, I was continuing with git-update-cache.\n\nThan I saw the examples creating-section and was bored, because I simply\nwant to test git with cinit.\n\nA `find .git` showed what files exist to me before, so git-cat-file\nand co. where not so interesting.\n\nI wanted to know, how to add all files from cinit. Then I was searching\nfor recursive adding, with exclusion. I did not get that easily\nwork with git-add-script. So I was searching through the git main\ndocumentation, found cogito and the hint not to use directly. Fine, let's\ntry cogito.\n\nIt look(s|ed) much easier, but had some errors (which pasky now fixed).\n\nThan I tried gitweb.cgi, which seems to have a small bug validating input:\n\n   if ($input =~ m/(^|\\/)(|\\.|\\.\\.)($|\\/)/) {\n\nThis also matches a cLinux/cinit.git as far as I can see.\nI use '(^|\\/)(\\.\\.|\\.)($|\\/)' currently, but I am not totally sure, whether\nthis is correct.\n\nYou can see the original version on\nhttp://linux.schottelius.org/cgi-bin/gitweb-orig.cgi\nand my modified version on\nhttp://linux.schottelius.org/cgi-bin/gitweb.cgi\n\nBut perhaps the logic in gitweb.cgi should be changed:\n\n[...]\nif (defined $project) {\n   $project = validate_input($project);\n   if (!defined($project)) {\n      die_error(undef, \"Invalid project parameter.\");\n   }\n   if (!(-d \"$projectroot/$project\")) {\n      undef $project;\n      die_error(undef, \"No such directory.\");\n   }\n[...]\n\nInstead of using -d at this section, one should test, whether the project\nis in the list of projects. A simple loop through the array\ngit_read_projects() returns should be enough.\n\n> \".git/remotes\" is the current one; \".git/branches\" is obsolete.\n\nWill .git/branches be complety removed later?\n\nHopefully some of you are now as confused as I've been,\n\nGood night,\n\nNico\n\n-- \nLatest project: cconfig (http://nico.schotteli.us/papers/linux/cconfig/)\nOpen Source nutures open minds and free, creative developers.\n"},{"id":"8807","messageId":"20050918213913.GC13315@vrfy.org","threadId":"1845","inReplyTo":"20050918211855.GA1463@schottelius.org","subject":"Re: first impressions to git","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-09-18T21:39:13Z","receivedAt":"2005-09-18T21:39:13Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Sun, Sep 18, 2005 at 11:18:56PM +0200, Nico -telmich- Schottelius wrote:\n> First of all, thanks for that many very good explaining answers.\n\n> Than I tried gitweb.cgi, which seems to have a small bug validating input:\n> \n>    if ($input =~ m/(^|\\/)(|\\.|\\.\\.)($|\\/)/) {\n> \n> This also matches a cLinux/cinit.git as far as I can see.\n> I use '(^|\\/)(\\.\\.|\\.)($|\\/)' currently, but I am not totally sure, whether\n> this is correct.\n\nIt fails cause you have a \"non canonical\" file name with a trailing\nslash.\n\n> You can see the original version on\n> http://linux.schottelius.org/cgi-bin/gitweb-orig.cgi\n> and my modified version on\n> http://linux.schottelius.org/cgi-bin/gitweb.cgi\n> \n> But perhaps the logic in gitweb.cgi should be changed:\n\nJust remove the trailing slash from your project name and everything\nshould be fine.\n\nKay\n"},{"id":"8809","messageId":"7vk6he110j.fsf@assigned-by-dhcp.cox.net","threadId":"1845","inReplyTo":"20050918211855.GA1463@schottelius.org","subject":"Re: first impressions to git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T22:09:32Z","receivedAt":"2005-09-18T22:09:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nico -telmich- Schottelius <nico-linux-git@schottelius.org> writes:\n\n> [22:29] hydrogenium:git-core-0.99.6% ls git-update-*\n> git-update-cache  git-update-server-info\n>\n> http://www.kernel.org/pub/software/scm/git/docs/tutorial.html (v0.99.5, Aug 2005):\n>\n> \"The first step is trivial: when you want to tell git about any changes to your working tree, you use the git-update-index program.\"\n\nThis is my fault.  The on-line documentation on kernel.org\nalways follow what is in the \"master\" branch that is a bit ahead\nof the last released version.\n\nAlso, the version number on each of the page does not\nnecessarily match the version of the software -- it gets updated\nto reflect the version of the last update of the doc, so the\npages reachable from git.html show different versions.\n\nBut still when you saw us talk about \"git-update-index\" and saw\nyou only have \"git-update-cache\", you could have looked at\ngit.html documentation page and find out that it says the\ncommand git-update-index was previously known as\ngit-update-cache.\n\n>> .git/description is actually a gitweb feature, not a core git feature. \n>> You'd only set it up for public repositories that you want to describe.\n>\n> That does not fit to what I see here:\n>\n> [22:46] hydrogenium:gpm% git-init-db \n> defaulting to local storage area\n> [22:46] hydrogenium:gpm% ls .git \n> branches  description  HEAD  hooks  info  objects  refs  remotes\n\nYou two are both right.  Git itself does not look at\ndescription, but just as a convenience it shows where to put\nthat file if you ever want to publish it from its built-in\ntemplates.\n\n>> \".git/remotes\" is the current one; \".git/branches\" is obsolete.\n>\n> Will .git/branches be complety removed later?\n\nThat is what the word deprecated usually means.  For now both\nare supported.\n"},{"id":"8810","messageId":"20050918221125.GD22391@pasky.or.cz","threadId":"1845","inReplyTo":"20050918211855.GA1463@schottelius.org","subject":"Re: first impressions to git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-18T22:11:25Z","receivedAt":"2005-09-18T22:11:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Sep 18, 2005 at 11:18:56PM CEST, I got a letter\nwhere Nico -telmich- Schottelius <nico-linux-git@schottelius.org> told me that...\n> Adrien Beau [Sun, Sep 18, 2005 at 04:33:05PM +0200]:\n> > Note that there is a problem if a Git-unaware daemon is used on the\n> > server (typical in the case of HTTP and rsync). If someone pulls while\n> > a push is in progress, references to not-yet-uploaded objects can be\n> > retrieved.\n> \n> Well, this will most likely happen often or how do you normally publish\n> your famous .git-directory?\n\nI think it should actually never happen, updating the references should\nalways come as the last thing in the push (or pull, for that matter)\nprocess.\n\n> > I'd be much obliged if you could tell me where the documentation lost you; \n> > it's really hard to document effectively without the assistance of someone \n> > who doesn't already know the program.\n> \n> Well, my way was:\n> \n> - find git [http://www.kernel.org/pub/software/scm/git/]\n> - find documentation [http://www.kernel.org/pub/software/scm/git/docs/]\n> - find step-by-step doc\n>    [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html]\n> \n> So far so fine, than I found the git-update-index/cache thing, which confused\n> me, I was not sure, whether this documentation fits only partly to git\n> or absolutely not. Still, I was continuing with git-update-cache.\n\nI believe it'd be a much more reasonable and less confusing policy for\nGit to have the docs for the last release on the web. (Cogito always had\nit this way, for that matter. ;-)\n\n> > \".git/remotes\" is the current one; \".git/branches\" is obsolete.\n> \n> Will .git/branches be complety removed later?\n\nIf that'd be the case, .git/branches is so widespread that at least\nCogito would move its content to .git/remotes automagically at some\npoint (it was doing such things in the past and it worked out well).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"8813","messageId":"7v7jde10dm.fsf@assigned-by-dhcp.cox.net","threadId":"1845","inReplyTo":"20050918221125.GD22391@pasky.or.cz","subject":"Re: first impressions to git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T22:23:17Z","receivedAt":"2005-09-18T22:23:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> I believe it'd be a much more reasonable and less confusing policy for\n> Git to have the docs for the last release on the web.\n\nMakes sense.  Either that, or have two links for the last\nreleased version and the in-development version.\n"},{"id":"8814","messageId":"Pine.LNX.4.58.0509181526220.9106@g5.osdl.org","threadId":"1845","inReplyTo":"20050918221125.GD22391@pasky.or.cz","subject":"Re: first impressions to git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-18T22:29:45Z","receivedAt":"2005-09-18T22:29:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Sep 2005, Petr Baudis wrote:\n> \n> I think it should actually never happen, updating the references should\n> always come as the last thing in the push (or pull, for that matter)\n> process.\n\nIt happens when you have several layers of non-git-aware stuff in between.\n\nOn kernel.org it happens occasionally with the mirroring, for example. I \npush something out while a mirror event is active, and the mirroring ends \nup finding the refs before the objects.\n\nThe same could happen with a write-back distributed networked filesystem,\nfor example (not NFS, which is synchronous in metadata, but some other\nlevel of non-git-aware thing that doesn't necessarily maintain write\nordering).\n\nIn general, git does the right thing for anything that honors write \nordering, but the fact is, there are things that don't.\n\n\t\tLinus\n"},{"id":"8893","messageId":"20050919191428.GG15165MdfPADPa@greensroom.kotnet.org","threadId":"1845","inReplyTo":"20050918111259.GA10882@schottelius.org","subject":"Re: first impressions to git","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-09-19T19:14:28Z","receivedAt":"2005-09-19T19:14:28Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Sun, Sep 18, 2005 at 01:12:59PM +0200, Nico -telmich- Schottelius wrote:\n> - gitweb.cgi could be better documentated and supported\n>    recursive directories when using $projects_list = $projectroot;\n>    and splitting configuration completly outside of gitweb.cgi would be nice\n>    (having .gitweb in the same directory as gitweb.cgi for instance)\n\nIf you don't mind running an \"unofficial\" gitweb, then you could use this:\n\nhttp://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=commitdiff;h=4e9ef72b3ad9a072c3b3a78d8f44ef7d592b7303;hp=cf893c76de670164e8d90be5ccf1d871e60188ae\n\nskimo\n"}]}