dist-hg proof-of-concept ready for use

[Dan Williams]

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 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

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 at mentok repo]$ export GIT_AUTHOR_NAME="Jesse Keating"
> [jkeating at 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 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.

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-maintainers