Re: Difficulties in advertising a new branch to git newbies

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 31, 2007, 16:15 UTC
Message-ID: <Pine.LNX.4.63.0701311708470.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <87k5z3npsz.wl%cworth@cworth.org>

Hi,

On Wed, 31 Jan 2007, Carl Worth wrote:

Show 8 quoted lines

> On Wed, 31 Jan 2007 14:13:42 +0100, "Guilhem Bonnefille" wrote:
> > If the user is not a developer and only interested in testing, what
> > about a simple snapshot tarball?
> > So, you prepare the fix and then you pack everything in a
> > myapp-timestamp.tar.gz and send this tarball to the user.
> 
> That's bad for all the same reasons we don't send tarballs around to 
> each other.

Well, that's not completely fair. Guilhem has a point here.

> 1. I want to be able to easily publicize a new branch with
>    instructions that anyone can use, (regardless of git experience).

How about gitweb, with a snapshot link? It's as easy as it gets. Even 
those Windows idio^H^H^H^Husers can unpack tar.gz files by now, and you 
send them just a link. They can even see what was fixed, and when, if they 
care enough.

> > 2. I've got the stuff available in a git branch already, and I don't
>    want to do any more work.

That is one of the lousiest excuses in this world. Unfortunately, I hear it very, very often. (I mean the second sentence.)

> 3. I want the exchange to be as efficient as possible, (I might send
>    multiple fixes in series to the user and it'd be really nice to
>    take advantage of git's efficiency here).

There's two kinds of efficient here. Efficient in the sense of network traffic, or in the sense of time spent talking back and forth, until the package is finally tested.

If the efficiency you are thriving for is network traffic, go a head, make the user use git.

However, if it is the other efficiency you want to achieve, stay away from git. Chances are that your user will never appreciate what git can to for her, and just wants to test the darned package, and be done with it, thank you very much.

Show 6 quoted lines

> 4. I don't want to condemn the user to never being able to learn
>    git. If I make this easy for the user then I get a nice lead-in to
>    teach the user new things, (which is good for me since it helps me
>    if the user starts sending me git commits rather than random
>    patches without commit messages connected to who-knows-what
>    tar-file version of the software, etc.)

That's nice of you. But it might just be that you royally p*ss the customer off, because he does not have time for that game.

Ciao, Dscho