On Tue, 2006-11-14 at 08:31 -0500, Jesse Keating wrote: > 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 I think you have to touch your ~/.hgrc file or something in your project with mercurial too. Unless I'm mistaken this is common to both systems (?). > [jkeating@mentok repo]$ export GIT_AUTHOR_NAME="Jesse Keating" > [jkeating@mentok repo]$ export GIT_COMMITTER_NAME="Jesse Keating" Again, the "power" of git strikes; you can have different commit/author names for every repo if you edit <repo>/.git/something-thats-really-obscure, but you can/have to do the same thing with mercurial too IIRC. > [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. Right; otherwise you get to specify the files you'd like to commit on the same line, as in 'git commit foo.c bar.c'. If you want to do a blanket commit, you must use '-a' which I can only assume means "all". I just _know_ somebody will suggest shell aliasing; but that indicates that the interaction is fundamentally broken already if you have to resort to aliasing. WTF is a 'commit' for if not to commit what you have changed?!!! I shouldn't have to specify an additional '-a' since I already told it to 'commit' explicitly. I suspect that the default behavior will actually never change because then kernel developers will complain loudly and guess who probably gets listened to more... In the end, the commit behavior here is something you likely just have to learn to deal with, as with things like mercurial's branching/merging strategy junk which git handles more or less automatically. Dan > > > > > 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. > > -- > Fedora-maintainers mailing list > Fedora-maintainers@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- 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
