dist-hg proof-of-concept ready for use

[Jesse Keating]

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 at mentok ~]$ mkdir repo
[jkeating at mentok ~]$ cd repo
[jkeating at mentok repo]$ git init-db
defaulting to local storage area
[jkeating at mentok repo]$ echo "I am a cool file" > coolfile
[jkeating at mentok repo]$ git add coolfile 
[jkeating at mentok repo]$ git status
#
# Initial commit
#
#
# Updated but not checked in:
#   (will commit)
#
#       new file: coolfile
#
[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.

fatal: empty ident  <jkeating at mentok.boston.redhat.com> not allowed

[jkeating at mentok repo]$ export GIT_AUTHOR_NAME="Jesse Keating"
[jkeating at mentok repo]$ export GIT_COMMITTER_NAME="Jesse Keating"
[jkeating at mentok repo]$ git commit
Committing initial tree 7492deb01e3f006ffbd8549e930b537d2339ae56
[jkeating at mentok repo]$ echo "I have more lines" >> coolfile 
[jkeating at 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 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]$ 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 at mentok repo]$ git-update-index
[jkeating at 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 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]$ @(*#^$(*&@^^

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
-------------- 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/a441ddec/attachment.sig>