On Tue, 14 Nov 2006 08:31:41 -0500, Jesse Keating wrote: > 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. I know I'll be interested in seeing that comparison. Git has some potential for doing better here since its packs can take advantage of inter-file similarities for compression, which hg's per-file storage cannot. But I don't have any idea which tool wins in general. > So here is what hit me: [snip of initial part of git interaction that looks sane and basically identical to hg] > [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. So, here git is refusing to create (indelible) history without proper attribution. That's a good thing, (why's your gecos information missing, by the way?). Meanwhile, git does give sufficient guidance here for you to fix the problem. > [jkeating@mentok repo]$ git commit > # > # Changed but not updated: > # (use git-update-index to mark for commit) > # > # modified: coolfile > # [...] > [jkeating@mentok repo]$ git-update-index [...] > [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]$ @(*#^$(*&@^^ OK. That's definitely a UI bug. Here git failed to give you the proper guidance for achieving what you wanted to do. Here's a proposed fix. If the original message saying: (use git-update-index to mark for commit) had instead said: (use "git commit <files>" to commit or "git commit -a" for all) would that have solved the problem? It would have at least prevented your wild goose chase through the documentation looking for this thing called an "index", (which I agree new users shouldn't have to care about to just commit a first change to a file). I've just submitted a patch for that to upstream git, and we can all watch to measure the responsiveness of the maintainers. > > > 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. There is definitely some misinformation behind your statements here. First, Linus is not the maintainer of git, nor has he been for quite a long time. Junio Hamano is the maintainer, and has proven to be very responsive to all the user-interface changes I've proposed, (either accepting them or providing reasonable rationale for the situation). I don't think all git UI bugs are worked out yet, but I don't see anything unfixable. As for "git commit -a", that is still a bit of a UI wart for users who expect "commit" to accept the entire state of the working tree. I had a lively debate with Linus early in my usage of git about this issue, and he stated strong opinions that the "index" is an important concept in git, it's useful as a "staging area" for the commit, and that it should be introduced to new users immediately, rather than be hidden by the UI for the most part. Meanwhile, Junio recently said that the "update-index" command should be treated as plumbing, not porcelain, (which means that git-commit's message directing users to "update-index" is definitely a bug). So there's evidence that the current git maintainer is listening to UI concerns from new users, even when contrary to Linus' original opinions on the UI. I think the logical next conclusion is that the "git commit -a" behavior should be the default. There is even a handy alias feature in git now, (which I mention not to say that all new users should manually install the "make the UI sane" aliases, but that the aliases can be used by experienced users to withstand changes in the defaults). And as evidence that git UI does improve, it used to be that the -a option to git-commit didn't even exist. > > > 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. I'm a Red Hat employee, and I feel I've been successful at helping git to be more intuitive and less confusing. I've not seen any discussions end in a brick wall on the git mailing list since I've been reading it (January 2006). But the really important point is that little things like "-a or no -a" are truly minor and can be changed without impact on the actual data stored in the repository. On the other hand, if there are issues about the robustness of the data stored in the repository, that's a much harder thing to fix, so I would argue that the repository storage is a much more significant distinction to make in selecting a system. (And this is after discarding things like cvs and svn for simply not being able to provide the functionality that is desired.) -Carl
Attachment:
pgpuJA54krCdz.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
