Re: Extract Git classes from git-svn (1/10)

From: Eric Wong <normalperson@yhbt.net>
Date: Jul 25, 2012, 02:55 UTC
Message-ID: <20120725025507.GB13236@dcvr.yhbt.net>
In-Reply-To: <500F23E4.9090306@pobox.com>

Michael G Schwern <schwern@pobox.com> wrote:

Show 19 quoted lines

> On 2012.7.17 10:49 PM, Junio C Hamano wrote:
> > By allowing people to easily publish a completed work, and making it
> > easier for them to let others peek at their work, Git hosting
> > services like GitHub are wonderful.  But I am not conviced that
> > quality code reviews like we do on the mailing list can be done with
> > existing Web based interface to a satisfactory degree.
> 
> In this instance, I was just using Github for repository storage.  I was
> hoping I could just submit a remote git repository and people would look at it
> from there.  No Github required.
> 
> I understand this makes things very convenient for you to review patches, let
> me convey my POV...
> 
> After I'm exhausted from volunteering all the coding work, rather than
> submitting a URL to a remote repository I find I have to learn new specialized
> tools.  It's extra learning and work, an extra step to screw up, and foreign
> to me (even as a experienced git user).  It is of little benefit to me as a
> casual volunteer submitter.

Except git is also a "new specialized tool". Your examples are exactly why I'm saddened many projects only adopted git, but not the workflow which _built_ git (and Linux).

> I can see if you've been on the git mailing list for a while and have git-am
> and all that set up, this system is great.  But it comes at a cost which is
> offloaded onto new and casual contributors.

Email is integral to Free/Open Source development and remains one of the few things on the Internet not (yet) controlled by any central entity. Once setup, the same email setup can work across all projects which use email. These projects need not be hosted on the same websites/servers at all.

Show 9 quoted lines

> This sort of specialized setup makes people bounce right off the submission
> process.  At OSCON I was asking around for help getting things setup so I
> could submit patches here properly.  As soon as they said "which mail daemon
> are you running?", I said "stop!  I don't want to know any more".  I have too
> many things to do to be fiddling with my mailer configuration just to submit
> volunteer work in the right form (that said, I'm pleased as punch that
> git-send-email now has instructions for sending via GMail).  You're
> volunteers, too.  We're all volunteers, so a more balanced submission process
> would be nice.

How about we educate users about a proper email setup instead? If they're capable of learning git, they're surely capable of setting up an email client properly, and perhaps more projects can adopt an email-centric workflow.

> But since you brought Github up... (I get the impression its kind of a dirty
> word around here)

(Not speaking for the git project) I'm entirely against the way GitHub (or Ohloh or similar services) gamifies software development and tries to tie a person to all their other projects.

Much of my code is public, but I am a private person. I want code to be judged solely on its own merits of that code; not from what the author's achieved or how "popular" the person might be in the development world. Unfortunately, GitHub (and other social networks) is structured to encourage that sort of thing (which I know is appealing to many).

For me, the whole social network followers/timeline thing also has a _huge_ creepiness factor to it. How one prioritizes and spends time between different different (especially unrelated) projects should be nobody else's business.

I don't make it /easy/ for someone (e.g. Junio) to know I'm slacking off on my git work to hack on ProjectNoOneUses :)

One could try using a different account for every project, but that's also violating the terms of service.

> If all the clicking and opening tabs in a browser feels uncomfortable to
> you... its something you learn like anything else.  Less and less people are
> comfortable in mail clients.  Who is the system optimized for?  It doesn't
> have to be a zero sum game.

(Still not speaking for others)  I believe GUIs are (mostly) harmful.

Graphical browsers don't interact well with command-line tools. Browsers have no concept of a working directory; I can't fire up a browser tab/window for each project I work on and edit/apply patches directly from the browser like I can with an MUA.

We need to figure out how to teach folks to use email (properly) instead.