On Mon, May 30, 2005 at 01:00:42PM -0700, Linus Torvalds wrote: > > Ok, I'm at the point where I really think it's getting close to a 1.0, and > make another tar-ball etc. I obviously feel that it's already way superior > to CVS, but I also realize that somebody who is used to CVS may not > actually realize that very easily. > > So before I do a 1.0 release, I want to write some stupid git tutorial for > a complete beginner that has only used CVS before, with a real example of > how to use raw git, and along those lines I actually want the thing to > show how to do something useful. > > So before I do that, is there something people think is just too hard for > somebody coming from the CVS world to understand? I already realized that > the "git-write-tree" + "git-commit-tree" interfaces were just _too_ hard > to put into a sane tutorial. > > I was showing off raw git to Steve Chamberlain yesterday, and showing it > to him made some things pretty obvious - one of them being that > "git-init-db" really needed to set up the initial refs etc). So I wrote > this silly "git-commit-script" to make it at least half-way palatable, but > what else do people feel is "too hard"? I finally got around to actually trying to use git to maintain the cpufreq repository the last few days after reading Jeff Garzik's mini-howto[1] It's not particularly complicated, but the number one thing that's bugged me is this.. # commit changes GIT_AUTHOR_NAME="John Doe" \ GIT_AUTHOR_EMAIL="jdoe@foo.com" \ GIT_COMMITTER_NAME="Jeff Garzik" \ GIT_COMMITTER_EMAIL="jgarzik@pobox.com" \ git-commit-tree `git-write-tree` \ -p $(cat .git/HEAD ) \ < changelog.txt \ > .git/HEAD For merging a lot of csets, thats a lot of typing per cset. So my .bashrc now sets up GIT_COMMITTER_NAME & GIT_COMMITTER_EMAIL, because I don't foresee myself changing either of those anytime soon, which takes it down to GIT_AUTHOR_NAME="John Doe" \ GIT_AUTHOR_EMAIL="jdoe@foo.com" \ git-commit-tree `git-write-tree` \ -p $(cat .git/HEAD ) \ < changelog.txt \ > .git/HEAD per-cset. Maybe I have early on-set dementia, but the number of times I've typoed those two remaining environment variables is bizarre. I must've hit every known combination possible in my merge of ~30 patches. I could make the latter 4 lines of the above a shell alias to save some typing, but those shell vars still bug me. Hmm, maybe I could create a wrapper that splits a "Dave Jones <davej@redhat.com" style string into two vars. I realise you've got a nifty bunch of tools to apply a whole mbox of patches, but that's not ideal if all of my patches aren't in mboxes (some I create myself and toss in my spool, some I pull from bugzilla etc..) Typos aside, the other thing that seems non-intuitive is the splitting up of the patch & changelog comment into seperate files during the patch-apply stage. Maybe your new git-commit-script wonder-tool fixes up all these problems already, I'll take a look after food. Its pretty nifty stuff, but for merging a lot of patches in non-mbox format, either I'm doing something wrong, or its, well.. painful. Dave [1] http://lkml.org/lkml/2005/5/26/11/index.html - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue May 31 08:12:44 2005
This archive was generated by hypermail 2.1.8 : 2005-05-31 08:12:45 EST