dist-hg proof-of-concept ready for use

[Carl Worth]

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 at 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 at mentok repo]$ git commit
> #
> # Changed but not updated:
> #   (use git-update-index to mark for commit)
> #
> #       modified: coolfile
> #
[...]
> [jkeating at mentok repo]$ git-update-index
[...]
> [jkeating at mentok repo]$ git commit
> #
> # Changed but not updated:
> #   (use git-update-index to mark for commit)
> #
> #       modified: coolfile
> #
> nothing to commit
> [jkeating at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20061114/9214c179/attachment.sig>