{"thread":{"id":"4922","subject":"Git BOF notes","startedAt":"2006-07-19T23:01:55Z","lastAt":"2006-07-24T12:08:09Z","messageCount":17,"participants":["Petr Baudis","J. Bruce Fields","Alex Riesen","Johannes Schindelin","Timo Hirvonen","Nguyễn Thái Ngọc Duy","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23937","messageId":"20060719230155.GJ13776@pasky.or.cz","threadId":"4922","inReplyTo":null,"subject":"Git BOF notes","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-19T23:01:55Z","receivedAt":"2006-07-19T23:01:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\n a short summary of the Git BOF on OLS which finished just a short\nwhile ago. We got to hear how Len Brown is doing things and where Git\ngets in the way for him as well as interesting questions and comments\nfrom several other people. The main highlights as I feel them (mixed\nrandomly with my personal blabbering) are that:\n\n (i) We should somehow separate the lowlevel Git commands from the\nhighlevel ones meant for user consumption. There's too many of them\nand it is confusing for the users. Similarity with BitKeeper was pointed\nout (and I refrained from mentioning GNU Arch).\n\n (ii) We should document the workflows better. Currently there is a\nhuge variety of workflows spread accross the Git user community,\nprobably stemming from the fact that the UI evolved so fast while\nalready \"on the fly\". Of course it shows that the Git tools are\nreally flxible and versatile, but it might also mean that we are not\nabstracting some operations enough, or not selling the easier user\ninterface better. Anyway, new users might find the current mix of\nworkflows used across the community somewhat intimidating. This also\nmeans that....\n\n (iii) ...we should spread the word about StGIT more (because StGIT\nis cool and often does just what people want to do with Git and it's\nclumsy), more so because...\n\n (iv) ...we should support mutating history better (I think this is the\nmost important point). There is a kind of conflict here:\n\n\t* Fundamentally, Git considers history to be immutable,\n\t especially if you publish it.\n\t* The kernel workflow encourages the opposite - the subsystem\n\t maintainers are rebasing all the time as well as just\n\t generally retouching their history (typos, fixing bugs in\n\t the patches etc).\n\n This problem can be separated to two areas:\n\n\t* Support for the history mutation. We have some nice tools\n\t in Git for rebasing, but it would be nice to support the\n\t other modifications easier as well. I suggested having\n\t a tool you just tell a commit id and it will let you modify\n\t the author info, the associated patch or fold another patch\n\t in... Also, using StGIT obviously hlps a lot here.\n\n\t* Support for distributing and following the mutated history.\n\t I'm actually not sure about the level of Git support for\n\t this, Cogito supports cg-updating to a mutated history\n\t if you have no local changes.\n\n Please feel free to add things if I have missed anything.\n\n Happy hacking,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23973","messageId":"20060721131824.GC32585@fieldses.org","threadId":"4922","inReplyTo":"20060719230155.GJ13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-07-21T13:18:24Z","receivedAt":"2006-07-21T13:18:24Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:\n> (i) We should somehow separate the lowlevel Git commands from the\n> highlevel ones meant for user consumption. There's too many of them\n> and it is confusing for the users. Similarity with BitKeeper was pointed\n> out (and I refrained from mentioning GNU Arch).\n\nThe man page already attempts to make this distinction in its command\nlist, though arguably the order is wrong (it lists the low-level\ncommands first) and you could argue about some of the choices (git\ninit-db may be \"low level\", but it's something everyone probably wants\nto see).\n\n\"git help\" already has an abbreviated list. What else could we do?\n\n--b.\n"},{"id":"23974","messageId":"20060721132111.GD32585@fieldses.org","threadId":"4922","inReplyTo":"20060719230155.GJ13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-07-21T13:21:11Z","receivedAt":"2006-07-21T13:21:11Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:\n> \t* Support for distributing and following the mutated history.\n> \t I'm actually not sure about the level of Git support for\n> \t this, Cogito supports cg-updating to a mutated history\n> \t if you have no local changes.\n\nA fetch that doesn't fast-forward fails with a warning unless you\nexplicitly ask it (--force) to blow away your old history.\n\nI don't see what more you could do.\n\n--b.\n"},{"id":"23975","messageId":"20060721143115.GN13776@pasky.or.cz","threadId":"4922","inReplyTo":"20060721132111.GD32585@fieldses.org","subject":"Re: Git BOF notes","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-21T14:31:16Z","receivedAt":"2006-07-21T14:31:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 21, 2006 at 03:21:11PM CEST, I got a letter\nwhere \"J. Bruce Fields\" said that...\n> On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:\n> > \t* Support for distributing and following the mutated history.\n> > \t I'm actually not sure about the level of Git support for\n> > \t this, Cogito supports cg-updating to a mutated history\n> > \t if you have no local changes.\n> \n> A fetch that doesn't fast-forward fails with a warning unless you\n> explicitly ask it (--force) to blow away your old history.\n\nI don't know if there's a point in being so paranoid - it already makes\nthings more painful than necessary. In the tracking branch, you just\nwant to have what the other side has anyway, and if the other side\ndecided to jump around, why would you care otherwise?\n\nJust make sure you print the original commit ID and perhaps a warning.\n\n> I don't see what more you could do.\n\nI guess a huge majority of Git users is an - almost inherently - silent\nmass of those who just use Git for tracking the development of others,\nand we gotta make it easy for them - and it's not easy if when the\nremote side rebases it doesn't just move them to the new commit but\nhelpfully offers a nonsensical three-way merge.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23976","messageId":"20060721144249.GO13776@pasky.or.cz","threadId":"4922","inReplyTo":"20060721131824.GC32585@fieldses.org","subject":"Re: Git BOF notes","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-21T14:42:51Z","receivedAt":"2006-07-21T14:42:51Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 21, 2006 at 03:18:24PM CEST, I got a letter\nwhere \"J. Bruce Fields\" said that...\n> On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:\n> > (i) We should somehow separate the lowlevel Git commands from the\n> > highlevel ones meant for user consumption. There's too many of them\n> > and it is confusing for the users. Similarity with BitKeeper was pointed\n> > out (and I refrained from mentioning GNU Arch).\n> \n> The man page already attempts to make this distinction in its command\n> list, though arguably the order is wrong (it lists the low-level\n> commands first) and you could argue about some of the choices (git\n> init-db may be \"low level\", but it's something everyone probably wants\n> to see).\n> \n> \"git help\" already has an abbreviated list. What else could we do?\n\nPerhaps (while coordinating with the porcelains, of course) we should\nstart moving the lowlevel tools to the libexec directory and keep only\nthe end-user tools around.\n\nYes, there is some blury stuff, but I think it's rather a sign that\nsomething is missing in the core Git porcelain. git-init-db is lowlevel\nand I think in 99% of the cases you are going to do an initial commit\nright after anyway, so you might as well just get git-init which does it\nfor you (something akin cg-init ;). I think we still tell users to use\ngit-update-index to mark resolved conflicts, but all the Git people at\nOLS were too afraid to even _mention_ the index to the users at all;\nshouldn't we have git-resolved instead?\n\nOh well, except that people are gonna run git-resolve instead all the\ntime. Why do we still _have_ that one?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23981","messageId":"81b0412b0607210802q4d48b277yc4c45d4acbd890a6@mail.gmail.com","threadId":"4922","inReplyTo":"20060721143115.GN13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-07-21T15:02:02Z","receivedAt":"2006-07-21T15:02:02Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 7/21/06, Petr Baudis wrote:\n> I don't know if there's a point in being so paranoid - it already makes\n> things more painful than necessary. In the tracking branch, you just\n> want to have what the other side has anyway, and if the other side\n> decided to jump around, why would you care otherwise?\n\nBut for the ones who do care, it is much harder to notice. Even if it is\na warning (it gets lost in crontab logs).\n"},{"id":"23986","messageId":"Pine.LNX.4.63.0607220212140.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4922","inReplyTo":"20060721144249.GO13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-22T00:17:48Z","receivedAt":"2006-07-22T00:17:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 21 Jul 2006, Petr Baudis wrote:\n\n> Yes, there is some blury stuff, but I think it's rather a sign that\n> something is missing in the core Git porcelain. git-init-db is lowlevel\n> and I think in 99% of the cases you are going to do an initial commit\n> right after anyway, so you might as well just get git-init which does it\n> for you (something akin cg-init ;).\n\nThink \"changed templates\". And also think \"setup a remote repository\", \nespecially \"setup a remote HTTP repository\". No, clone will not work if \nyou are sitting behind a firewall and/or DSL router (and who does not?).\n\nAnd also think \"start a new repository with only a _part_ of the current \nfiles\". There are plenty reasons -- in addition to separation of concepts \n-- not to commit straight after initializing a repository.\n\n> I think we still tell users to use git-update-index to mark resolved \n> conflicts, [...]\n\nI don't know, but I had the impression we'd tell them \"resolve your \nconflicts, and then do git-commit -a\". Which is good enough.\n\nCiao,\nDscho\n"},{"id":"23987","messageId":"20060722032200.GP13776@pasky.or.cz","threadId":"4922","inReplyTo":"Pine.LNX.4.63.0607220212140.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git BOF notes","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-22T03:22:00Z","receivedAt":"2006-07-22T03:22:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> On Fri, 21 Jul 2006, Petr Baudis wrote:\n> \n> > Yes, there is some blury stuff, but I think it's rather a sign that\n> > something is missing in the core Git porcelain. git-init-db is lowlevel\n> > and I think in 99% of the cases you are going to do an initial commit\n> > right after anyway, so you might as well just get git-init which does it\n> > for you (something akin cg-init ;).\n> \n> Think \"changed templates\".\n\n it may be that I'm just tired, but I don't see what you mean, sorry.\n\n> And also think \"setup a remote repository\", especially \"setup a remote\n> HTTP repository\".\n\n Of course. Currently you need to tinker with environment variables,\nthen with hooks, possibly with permissions and stuff to make the\nrepository shared... Think cg-admin-setuprepo. ;-)\n\n> And also think \"start a new repository with only a _part_ of the current \n> files\". There are plenty reasons -- in addition to separation of concepts \n> -- not to commit straight after initializing a repository.\n\n So what _do_ you do if you don't commit straight?\n\n Of course sometimes you don't want to add everything, and that should\nstill be possible to do (cg-init has a switch for that).\n\n> > I think we still tell users to use git-update-index to mark resolved \n> > conflicts, [...]\n> \n> I don't know, but I had the impression we'd tell them \"resolve your \n> conflicts, and then do git-commit -a\". Which is good enough.\n\n My comment there was based on the jdl's presentation at OLS. Sorry if\nin docs we are saying other things, I don't tend to lookat Git porcelain\ndocumentation. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"23988","messageId":"Pine.LNX.4.63.0607220547570.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4922","inReplyTo":"20060722032200.GP13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-22T03:55:59Z","receivedAt":"2006-07-22T03:55:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 22 Jul 2006, Petr Baudis wrote:\n\n> Hi,\n> \n> Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter\n> where Johannes Schindelin said that...\n> > On Fri, 21 Jul 2006, Petr Baudis wrote:\n> > \n> > > Yes, there is some blury stuff, but I think it's rather a sign that\n> > > something is missing in the core Git porcelain. git-init-db is lowlevel\n> > > and I think in 99% of the cases you are going to do an initial commit\n> > > right after anyway, so you might as well just get git-init which does it\n> > > for you (something akin cg-init ;).\n> > \n> > Think \"changed templates\".\n> \n> it may be that I'm just tired, but I don't see what you mean, sorry.\n\nIf you change a template (like add a hook or something), you can call \ngit-init-db in an existing repository to update that hook.\n\n> > And also think \"setup a remote repository\", especially \"setup a remote\n> > HTTP repository\".\n> \n> Of course. Currently you need to tinker with environment variables,\n> then with hooks, possibly with permissions and stuff to make the\n> repository shared... Think cg-admin-setuprepo. ;-)\n\ngit-init-db --shared\n\n> > And also think \"start a new repository with only a _part_ of the current \n> > files\". There are plenty reasons -- in addition to separation of concepts \n> > -- not to commit straight after initializing a repository.\n> \n> So what _do_ you do if you don't commit straight?\n\nSometimes, I do \"git-push just@initted.repository.com master\". From \nsomewhere else, of course.\n\nAt other times, I do \"git-add the-paper.tex && git commit initial\".\n\nAnd sometimes, I do \"cp -R /some/where/CVS ./; git-cvsimport\".\n\n> Of course sometimes you don't want to add everything, and that should\n> still be possible to do (cg-init has a switch for that).\n\nUsually I start small projects as a single .c or .java file. Only after a \nwhile, I think it is worth it to init a git database. So, I _always_ have \ngenerated files lying around. And I would hate it if they were checked in \nautomatically. (Yeah, I could remove them, _then_ remove them from the \nindex, and then git-commit --amend. Ugly.)\n\n> > > I think we still tell users to use git-update-index to mark resolved \n> > > conflicts, [...]\n> > \n> > I don't know, but I had the impression we'd tell them \"resolve your \n> > conflicts, and then do git-commit -a\". Which is good enough.\n> \n> My comment there was based on the jdl's presentation at OLS. Sorry if\n> in docs we are saying other things, I don't tend to lookat Git porcelain\n> documentation. ;-)\n\nThat makes two of us.\n\nCiao,\nDscho\n"},{"id":"23999","messageId":"20060722191652.GR13776@pasky.or.cz","threadId":"4922","inReplyTo":"Pine.LNX.4.63.0607220547570.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git BOF notes","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-22T19:16:52Z","receivedAt":"2006-07-22T19:16:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nDear diary, on Sat, Jul 22, 2006 at 05:55:59AM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> On Sat, 22 Jul 2006, Petr Baudis wrote:\n> > Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter\n> > where Johannes Schindelin said that...\n> > > Think \"changed templates\".\n> > \n> > it may be that I'm just tired, but I don't see what you mean, sorry.\n> \n> If you change a template (like add a hook or something), you can call \n> git-init-db in an existing repository to update that hook.\n\n ah well, I guess that's obscure enough to tell the user to directly\nrun git-init-db. ;-)\n\n> > > And also think \"setup a remote repository\", especially \"setup a remote\n> > > HTTP repository\".\n> > \n> > Of course. Currently you need to tinker with environment variables,\n> > then with hooks, possibly with permissions and stuff to make the\n> > repository shared... Think cg-admin-setuprepo. ;-)\n> \n> git-init-db --shared\n\nAnd the environment variable and the chgrp and g+s. That's my point.\n\n> > > And also think \"start a new repository with only a _part_ of the current \n> > > files\". There are plenty reasons -- in addition to separation of concepts \n> > > -- not to commit straight after initializing a repository.\n> > \n> > So what _do_ you do if you don't commit straight?\n> \n> Sometimes, I do \"git-push just@initted.repository.com master\". From \n> somewhere else, of course.\n\nI guess that's more common for the bare repositories.\n\n> And sometimes, I do \"cp -R /some/where/CVS ./; git-cvsimport\".\n\ngit-cvsimport will create the repository for you, won't it?\n\n> > Of course sometimes you don't want to add everything, and that should\n> > still be possible to do (cg-init has a switch for that).\n> \n> Usually I start small projects as a single .c or .java file. Only after a \n> while, I think it is worth it to init a git database. So, I _always_ have \n> generated files lying around. And I would hate it if they were checked in \n> automatically. (Yeah, I could remove them, _then_ remove them from the \n> index, and then git-commit --amend. Ugly.)\n\nCan't you just do make clean before git init? Or you can prepare\n.gitignore before you check stuff in, so that the autogenerated files\ndon't pollute your git status output. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"24001","messageId":"20060722230338.4ebcf7f8.tihirvon@gmail.com","threadId":"4922","inReplyTo":"20060722191652.GR13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-07-22T20:03:38Z","receivedAt":"2006-07-22T20:03:38Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Petr Baudis wrote:\n\n> > Usually I start small projects as a single .c or .java file. Only after a \n> > while, I think it is worth it to init a git database. So, I _always_ have \n> > generated files lying around. And I would hate it if they were checked in \n> > automatically. (Yeah, I could remove them, _then_ remove them from the \n> > index, and then git-commit --amend. Ugly.)\n> \n> Can't you just do make clean before git init? Or you can prepare\n> .gitignore before you check stuff in, so that the autogenerated files\n> don't pollute your git status output. ;-)\n\nI like git init-db as it is now. I don't want it to automatically add\nfiles. GIT does what you ask it to do, not what it _thinks_ you want to\ndo.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"24002","messageId":"fcaeb9bf0607221312k2088658bqa45e622b7fe244e4@mail.gmail.com","threadId":"4922","inReplyTo":"81b0412b0607210802q4d48b277yc4c45d4acbd890a6@mail.gmail.com","subject":"Re: Git BOF notes","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-07-22T20:12:07Z","receivedAt":"2006-07-22T20:12:07Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/21/06, Alex Riesen wrote:\n> On 7/21/06, Petr Baudis wrote:\n> > I don't know if there's a point in being so paranoid - it already makes\n> > things more painful than necessary. In the tracking branch, you just\n> > want to have what the other side has anyway, and if the other side\n> > decided to jump around, why would you care otherwise?\n>\n> But for the ones who do care, it is much harder to notice. Even if it is\n> a warning (it gets lost in crontab logs).\nThen create some lost+found branches for them?\n"},{"id":"24010","messageId":"20060723073818.GA5822@steel.home","threadId":"4922","inReplyTo":"fcaeb9bf0607221312k2088658bqa45e622b7fe244e4@mail.gmail.com","subject":"Re: Git BOF notes","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-23T07:38:18Z","receivedAt":"2006-07-23T07:38:18Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Nguyễn Thái Ngọc Duy, Sat, Jul 22, 2006 22:12:07 +0200:\n> >> I don't know if there's a point in being so paranoid - it already makes\n> >> things more painful than necessary. In the tracking branch, you just\n> >> want to have what the other side has anyway, and if the other side\n> >> decided to jump around, why would you care otherwise?\n> >\n> >But for the ones who do care, it is much harder to notice. Even if it is\n> >a warning (it gets lost in crontab logs).\n>\n> Then create some lost+found branches for them?\n\nif you copy files from ext3 to vfat, do you expect them to be found in\nlost+found? Usually not, I believe. It should either fail or copy.\n"},{"id":"24032","messageId":"Pine.LNX.4.63.0607240049500.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4922","inReplyTo":"20060722191652.GR13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-23T22:53:11Z","receivedAt":"2006-07-23T22:53:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 22 Jul 2006, Petr Baudis wrote:\n\n> Dear diary, on Sat, Jul 22, 2006 at 05:55:59AM CEST, I got a letter\n> where Johannes Schindelin said that...\n> > On Sat, 22 Jul 2006, Petr Baudis wrote:\n> > > Dear diary, on Sat, Jul 22, 2006 at 02:17:48AM CEST, I got a letter\n> > > where Johannes Schindelin said that...\n> > > > And also think \"setup a remote repository\", especially \"setup a remote\n> > > > HTTP repository\".\n> > > \n> > > Of course. Currently you need to tinker with environment variables,\n> > > then with hooks, possibly with permissions and stuff to make the\n> > > repository shared... Think cg-admin-setuprepo. ;-)\n> > \n> > git-init-db --shared\n> \n> And the environment variable and the chgrp and g+s. That's my point.\n\nI do not have the itch. But of course, it would be trivial to do that as \ncommand line options.\n\n> > And sometimes, I do \"cp -R /some/where/CVS ./; git-cvsimport\".\n> \n> git-cvsimport will create the repository for you, won't it?\n\nIt could, if I'd let it ;-)\n\n> > > Of course sometimes you don't want to add everything, and that should\n> > > still be possible to do (cg-init has a switch for that).\n> > \n> > Usually I start small projects as a single .c or .java file. Only after a \n> > while, I think it is worth it to init a git database. So, I _always_ have \n> > generated files lying around. And I would hate it if they were checked in \n> > automatically. (Yeah, I could remove them, _then_ remove them from the \n> > index, and then git-commit --amend. Ugly.)\n> \n> Can't you just do make clean before git init? Or you can prepare \n> .gitignore before you check stuff in, so that the autogenerated files \n> don't pollute your git status output. ;-)\n\nYes, I can. I also can type in several sheets of hex data. But I don't \nwant to. Like Timo, I am very happy to tell the computer what to do, not \nto let it take guesses.\n\nCiao,\nDscho\n"},{"id":"24055","messageId":"tnxmzaz5q3v.fsf@arm.com","threadId":"4922","inReplyTo":"20060719230155.GJ13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-07-24T09:06:28Z","receivedAt":"2006-07-24T09:06:28Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Petr Baudis wrote:\n> a short summary of the Git BOF on OLS which finished just a short\n> while ago. We got to hear how Len Brown is doing things and where Git\n> gets in the way for him as well as interesting questions and comments\n> from several other people. The main highlights as I feel them (mixed\n> randomly with my personal blabbering) are that:\n\nWhat I forgot to mention at the OLS - it would be useful for a more\nwide-spread adoption of GIT to convince some of the source code\nhosting sites (like sourceforge.net) to provide GIT support. For StGIT\nI currently use an HTTP server but that's not the most efficient way.\n\n-- \nCatalin\n"},{"id":"24060","messageId":"20060724114753.GT13776@pasky.or.cz","threadId":"4922","inReplyTo":"tnxmzaz5q3v.fsf@arm.com","subject":"Re: Git BOF notes","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-07-24T11:47:53Z","receivedAt":"2006-07-24T11:47:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Jul 24, 2006 at 11:06:28AM CEST, I got a letter\nwhere Catalin Marinas said that...\n> Petr Baudis wrote:\n> > a short summary of the Git BOF on OLS which finished just a short\n> > while ago. We got to hear how Len Brown is doing things and where Git\n> > gets in the way for him as well as interesting questions and comments\n> > from several other people. The main highlights as I feel them (mixed\n> > randomly with my personal blabbering) are that:\n> \n> What I forgot to mention at the OLS - it would be useful for a more\n> wide-spread adoption of GIT to convince some of the source code\n> hosting sites (like sourceforge.net) to provide GIT support. For StGIT\n> I currently use an HTTP server but that's not the most efficient way.\n\nActually, with recent (well, at least half a year ago the situation was\nlike that) quality of Sf.net's CVS hosting that might in fact give Git\nsome share of negative reputation if they provided a service of similar\nquality. I think some people from Savannah were actually interested in\nGit hosting, though.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"24061","messageId":"fcaeb9bf0607240508p197dccc5u8fdb7c92445323b5@mail.gmail.com","threadId":"4922","inReplyTo":"20060724114753.GT13776@pasky.or.cz","subject":"Re: Git BOF notes","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-07-24T12:08:09Z","receivedAt":"2006-07-24T12:08:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/24/06, Petr Baudis wrote:\n> Actually, with recent (well, at least half a year ago the situation was\n> like that) quality of Sf.net's CVS hosting that might in fact give Git\n> some share of negative reputation if they provided a service of similar\n> quality. I think some people from Savannah were actually interested in\n> Git hosting, though.\nI don't think so. Quotes from [1]:\nWhat about support for git / cogito?\nNo. Savannah can not support every versioning system. That's merely ludicrous.\n\n[1] http://savannah.gnu.org/forum/forum.php?printer=1&forum_id=3944\n"}]}