dist-hg proof-of-concept ready for use

[David Woodhouse]

On Mon, 2006-11-13 at 23:35 -0500, Jesse Keating wrote:
> On Monday 13 November 2006 23:30, David Woodhouse wrote:
> > You mean memory footprint? Can you show your measurements?
> 
> No, I meant on disk footprint.  Git repos, while smaller than CVS, are still 
> larger than hg.

Is the cost of disk a deciding factor? You were comparing fully packed
repositories, I hope?

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


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

-- 
dwmw2