On Mon, Jul 28, 2008 at 3:50 AM, Johannes Schindelin
wrote:
By all means! The users might be a bit confused about why you're
sending them to #github, but we're happy to help them out if you don't
care to. We actually employ a support person to man the channel and
help out where he can.
>> Perhaps it is the commercial aspect of GitHub that offends.
Using this same logic, it follows that we GitHub developers would be
better suited to hacking on GitHub (which would be good for the git
community). There are only so many hours in the day. I've had many a
GitHub user tell me that the GitHub interface and functionality helped
them finally understand git and feel comfortable switching to it from
SVN or CVS. It seems we can help bigger populations of git users by
making the site as clear and easy to use as possible, so that is what
we choose to do.
> - if your advices can be enhanced (such as my gripe that "git show" is not
Can you clarify what you are referring to here? I'm not sure I understand.
> - just as in the past, I fully expect the main thrust of the major changes
I totally agree with the direction that 1.5 has taken git. You guys
are doing an awesome job with user experience. As I come across
usability problems I'll be sure to bring them up here in the future.
>> Having had to implement a git-daemon replacement that fit our needs, I
The problem is that I'm only a casual C coder. It takes me a while to
figure out what's going on in the git source. We needed a way to serve
public git repositories from a hashed directory structure (e.g.
/a/b/c/user/repo.git) and we needed it fast. In a few days worth of
coding Erlang, I was able to meet that need (and also add logging and
better error messages returned to the client). If I had, as you
suggest, created a badly written patch and asked for help on the list,
I'd probably still be trying to solve the problem. It's dubious that
anyone other than us currently needs to satisfy the hashed directory
requirement, and as such I would not assume or expect that anyone
would be motivated to spend a bunch of time helping a C amateur
satisfy that need. In the end I was responsible for making it work,
and I did that the best and most efficient way I knew how.
Like I said before, I'm happy to share my suggestions for better error
messages and logging behavior, but I'm probably not going to be much
help with providing patches.
>> We like to design from first principles, see how good we can do, and
This is clearly false and does not do Junio or Shawn justice. It's not
hard to imagine that these two (or any of the other contributors)
could make money doing training for git at companies that have adopted
it, or as consultants to firms that use git in novel ways, or as
authors of git books. Scott Chacon gets paid right now to work on
tools that use git as an underlying file system. In fact, by helping
bring corporate interest to git, GitHub is paving the way for more and
more people to make money from git if they so choose. I wouldn't be
surprised if, down the road, Junio could be paid to hack on git full
time via corporate sponsorship. The continuing advancement of git is
of interest to a great many people. Some of which would gladly pay for
it.
Tom Preston-Werner
github.com/mojombo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Robin Lee Powell | NFS hang + umount -f: better behaviour requested. |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
