Heya, On Wed, Sep 9, 2009 at 23:27, Brendan Miller<catphive@xxxxxxxxxxxx> wrote: > 1. cloning from a new empty repo fails, and so do a lot of other > operations. This adds unnecessary steps to setting up a new shared > repo. Actually, it works in recent git. > 2. git --bare init. The flag goes before the operation unlike every other flag? Because unlike most flags it applies to anything git does, e.g. 'git --bare status' to treat the current directory as a git repository rather than looking for a .git directory. > 4. The index is inconsistently referred to as too many different > things (cache, index, staging area) and only the last one makes any > intuitive sense to a new user. This is partially a CLI issue, and > partially a documentation issue, but both add up to cause confusion. > > 5. Most commands require lots of flags, and don't have reasonable > defaults. e.g. archive. Most git commands need no more than two flags, and the defaults are reasonable to me; of course everybody has different needs, git aliasses make it easy to overcome this. > This is what I want to do 90% of the time, so it should just have the > proper defaults, and not make me look at the man page every time I > want to use it. Again, make an alias if you use it a lot; it might be what _you_ want to do, but as you can see from the plethora of other examples, it is perhaps not what everybody else wants to do 90% of the time. > 6. Where is the bug tracker? If people users can't find the bug > tracker, they can't report issues, and obnoxious bugs go unfixed, or > people have to whine on the mailing list. There should be a nice big > link on the front page of git-scm.com. A bug tracker is really the > only way for the vast majority of a community that use a tool can give > feedback on the problems the tool has. Nope, that's not how things work for us. We _want_ people to 'whine' on the mailing list, so that if they really don't care that much about something, it is "dropped on the floor" (because the thread becomes stale) after a while, and we move on. Bug trackers are notorious for growing in size very fast, and becoming cluttered (I have experience with this as well, and am very pleased with how the git's mailing list approach solves this). > 7. Man pages: It's nice we have them, but we shouldn't need them to do > basic stuff. I rarely had to look at the man pages using svn, but > every single time I use git I have to dig into these things. Frankly, > I have better things to do than RTFM. Honestly, you never had to consult the help for svn? Perhaps the help was not in a man page, but in some obscure website online; I for one welcome our on-disk information bringing overlords. > 8. There's no obvious way to make a remote your default push pull > location without editing the git config file. Why not just something > like > It's ok to have kind of a weak UI on a new tool, when people are busy > adding basic functionality. However, at this point git already has way > more features than most of the competition, and the needless > complexity of the CLI is the biggest issue in day to day use. If you don't need all that functionality, why not just use one of them fancy GUI's out there? -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html