On Tuesday 14 November 2006 01:17, David Woodhouse wrote: > Is the cost of disk a deciding factor? You were comparing fully packed > repositories, I hope? It's not a huge factor, but it is something to consider as we toss 5K packages on a server. Yes, I'm using fully packed repos as the reference point. Some package sets are actually larger than CVS, some are smaller. Once I've done the full conversion (takes much longer than with hg) I can do an overall comparison. The fact that I have to know about repacking, but not just repacking, repacking with special -a and -d flags just to get the damn thing to repack seems pretty ridiculous to me. Why wouldn't a cvs import automatically repack and prune after the import? > > > > B) a user experience that isn't a complete disaster, leading to > > > > multiple rewritten front ends that confuse the issue even further > > > > > > That was true a year or so ago because git itself basically _lacked_ a > > > front end. It's not the case any more. > > > > Not so. I ran into many issues just trying to do normal usage of git, > > that is create a repo, add a file, commit the file. > > Really? > > shinybook /home/dwmw2 $ mkdir foobar > shinybook /home/dwmw2 $ cd foobar > shinybook /home/dwmw2/foobar $ git-init-db > defaulting to local storage area > shinybook /home/dwmw2/foobar $ echo hello > newfile > shinybook /home/dwmw2/foobar $ git-add newfile > shinybook /home/dwmw2/foobar $ git-commit -m "Add new file" newfile > Committing initial tree 37f0960e8ef1d9eae41447271f51d579e3ee71ed > shinybook /home/dwmw2/foobar $ rsync -az .git/ > pentafluge.infradead.org:public_git/newrepo shinybook /home/dwmw2/foobar $ > lynx http://git.infradead.org/?p=users/dwmw2/newrepo So here is what hit me: [jkeating@mentok ~]$ mkdir repo [jkeating@mentok ~]$ cd repo [jkeating@mentok repo]$ git init-db defaulting to local storage area [jkeating@mentok repo]$ echo "I am a cool file" > coolfile [jkeating@mentok repo]$ git add coolfile [jkeating@mentok repo]$ git status # # Initial commit # # # Updated but not checked in: # (will commit) # # new file: coolfile # [jkeating@mentok repo]$ git commit *** Environment problem: *** Your name cannot be determined from your system services (gecos). *** You would need to set GIT_AUTHOR_NAME and GIT_COMMITTER_NAME *** environment variables; otherwise you won't be able to perform *** certain operations because of "empty ident" errors. *** Alternatively, you can use user.name configuration variable. fatal: empty ident <jkeating@xxxxxxxxxxxxxxxxxxxxxxxx> not allowed [jkeating@mentok repo]$ export GIT_AUTHOR_NAME="Jesse Keating" [jkeating@mentok repo]$ export GIT_COMMITTER_NAME="Jesse Keating" [jkeating@mentok repo]$ git commit Committing initial tree 7492deb01e3f006ffbd8549e930b537d2339ae56 [jkeating@mentok repo]$ echo "I have more lines" >> coolfile [jkeating@mentok repo]$ git diff diff --git a/coolfile b/coolfile index d5e8802..bde20c8 100644 --- a/coolfile +++ b/coolfile @@ -1 +1,2 @@ I am a cool file +I have more lines [jkeating@mentok repo]$ git commit # # Changed but not updated: # (use git-update-index to mark for commit) # # modified: coolfile # nothing to commit [jkeating@mentok repo]$ git diff diff --git a/coolfile b/coolfile index d5e8802..bde20c8 100644 --- a/coolfile +++ b/coolfile @@ -1 +1,2 @@ I am a cool file +I have more lines [jkeating@mentok repo]$ git-update-index [jkeating@mentok repo]$ git diff diff --git a/coolfile b/coolfile index d5e8802..bde20c8 100644 --- a/coolfile +++ b/coolfile @@ -1 +1,2 @@ I am a cool file +I have more lines [jkeating@mentok repo]$ git commit # # Changed but not updated: # (use git-update-index to mark for commit) # # modified: coolfile # nothing to commit [jkeating@mentok repo]$ @(*#^$(*&@^^ At this point I went on a wild goose chase on what the "index" was and why wasn't it being updated. It finally took reading every line of the commit man page to realize that unlike the first commit, I have to add a -a in order to commit any changes. > > > Things are not intuitive, the > > docs are extremely hard to follow, and I got told I need to update > > something called an index, which STILL didn't work. > > I strongly suspect that you (or those on whose information you're basing > your judgement) have not actually tried git this year. Or if you have, > you've been looking at horridly out of date documentation. > > > Asking around, everybody who uses > > git has ran into these same problems, and have even asked to get things > > fixed upstream but to no avail. Linus is not interested in changing how > > git works to have more sane defaults. That's fine, git works great for > > his usage case, not so much for our community of software packagers. > > Please, be specific. Ask Adam Jackson (ajax). > > > > > C) an upstream that is actually willing to listen to our problems > > > > and fix them or help us to fix them > > > > > > That seems rather strange to me. What causes you to believe that git > > > lacks such qualities in its upstream maintainers? (Sorry, my mail > > > server at home is temporarily dead so I can't easily look back at my > > > archives of the git mailing list). > > > > Reports from other Red Hat employees who have tried to get things changed > > upstream to be more intuitive and less confusing, basically meeting a > > brick wall. > > Do you have references to these discussions? Talk to Adam Jackson. -- Jesse Keating Release Engineer: Fedora
Attachment:
pgpP7lqSrCL93.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
