From: "Shawn O. Pearce" <spearce@spearce.org>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: Josh Boyer <jwboyer@gmail.com>, Junio C Hamano <junkio@cox.net>,
git@vger.kernel.org, davidk@lysator.liu.se
Subject: Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt
Date: Thu, 18 Jan 2007 10:42:57 -0500 [thread overview]
Message-ID: <20070118154257.GC15428@spearce.org> (raw)
In-Reply-To: <81b0412b0701180540x15d20453s3dbc0c061fd06d50@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> The _real_ majority of the programmers desperately need a better
> VCS than CVS, SVN, Perforce, SourceSafe, ClearCase, etc.
Yes. But...
Yesterday I had a conversation with the software configuration
management guy at my day-time-pays-the-bills organization.
They are seriously looking at Perforce and ClearCase, as these are
lightyears ahead of what we have already (PVCS Version Manager).
They also have 1-800-my-vendor telephone numbers which you can
call and scream at someone when the tool corrupts its internal
database[*1*], or when you cannot figure out what the "Checkout"
action in the context menu does[*2*].
However my fellow developers and I use Git. We export our changes
out to PVCS Version Manager via an *ugly* Perl script that I would
never actually wish on anyone (which is one reason why its not
contributed as git-pvcsexport). Configuration management guy won't
even look at Git's real strengths as it lacks the all-important
1-800-git-help[*3*] phone number.
Yesterday we spent 4 half-man-days (4 developers working together
all morning) trying to get a configuration of random files from
PVCS Version Manager which compiled. In Git this would have been as
simple as merging the two topics that management wanted moved to the
next level of testing. But since our organization doesn't actually
use Git and multiple topics affected the same files, well, yea, it
was a mess. Unfortunately calling 1-800-my-vendor yields a "don't do
that" from our vendor and nothing more in support. I'm very glad
we pay them for the privilege of having a 1-800-my-vendor phone
number in our rolodex. Yesterday it cost us over $1600 in labor.
> Yes. For me and you. One of my coworkers knows nothing about patches,
> but wants (and perfectly able to) review my code. He has usable brains
> and is able to figure out what "+" and "-" is (he has, by now). He hasn't
> even realized that it was an automatically generated information, as
> I sent a patch to him first time, thought it was just a funny way to
> document changes (and was surprised when I told him a patch can be
> applied automatically, even if the original file is not exactly the same).
> But he is a typical windows-trained programmer.
I work with a few people who would rather copy and paste their
changed parts into an email, then color them with pretty colors
like red, green, blue, black, orange in Outlook (and all in the
same email too). These then get sent to me for code review.
Prior to us using Git it may make some sense, as we did not have
a diff tool available. Now that everyone is using Git and working
in isolated topic branches (and doing very well with that concept)
I still get these emails. People seem to have an easy time grasping
the idea that Git is tracking their changes and when combined with
my git-pvcsexport (see above) it just Does The Right Thing(tm)
later on. But they have a hard time grasping the idea that Git can
export these as a diff, or that they could just push their topic
branch to me so I can pop it open in gitk. *sigh*
[*1*] This has happened to me with Perforce more than once. Not a
happy thought. Never with Git.
[*2*] Yes, really, some of our version control users have difficulty
grasping a concept like "checkout". They *definately* have
an issue with Git's "checkout -b" concept.
[*3*] Already taken. Oddly enough by a company that could almost
be considered to be a competiter to my day-time-pays-the-bills
organization.
--
Shawn.
next prev parent reply other threads:[~2007-01-18 15:43 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-17 13:10 [RFC] Add a suffix option to git-format-patch Josh Boyer
2007-01-17 13:49 ` Johannes Schindelin
2007-01-17 14:50 ` Josh Boyer
2007-01-17 16:39 ` Horst H. von Brand
2007-01-17 19:18 ` [PATCH] Introduce 'git-format-patch --suffix=patch' Junio C Hamano
2007-01-17 19:20 ` Andy Whitcroft
2007-01-17 19:27 ` Junio C Hamano
2007-01-17 19:51 ` Brian Gernhardt
2007-01-17 19:57 ` Junio C Hamano
2007-01-17 20:08 ` Brian Gernhardt
2007-01-17 20:22 ` [PATCH] Make format-patch --suffix="" not add any suffix Brian Gernhardt
2007-01-18 1:11 ` [PATCH] Introduce 'git-format-patch --suffix=patch' Johannes Schindelin
2007-01-17 15:43 ` [RFC] Add a suffix option to git-format-patch David Kågedal
2007-01-17 16:57 ` Andreas Ericsson
2007-01-17 17:05 ` Johannes Schindelin
2007-01-17 17:33 ` Junio C Hamano
2007-01-17 18:15 ` David Kågedal
2007-01-17 20:18 ` Josh Boyer
2007-01-17 20:20 ` Josh Boyer
[not found] ` <7vsle9p8pg.fsf@assigned-by-dhcp.cox.net>
2007-01-18 0:06 ` [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt Junio C Hamano
2007-01-18 1:06 ` Johannes Schindelin
2007-01-18 7:59 ` Alex Riesen
2007-01-18 8:06 ` Shawn O. Pearce
2007-01-18 8:18 ` Alex Riesen
2007-01-18 9:10 ` Junio C Hamano
2007-01-18 9:21 ` Alex Riesen
2007-01-18 8:43 ` Junio C Hamano
2007-01-18 9:35 ` Alex Riesen
2007-01-18 11:52 ` Josh Boyer
2007-01-18 13:33 ` Johannes Schindelin
2007-01-18 13:46 ` Alex Riesen
2007-01-18 13:40 ` Alex Riesen
2007-01-18 14:10 ` Andreas Ericsson
2007-01-18 14:15 ` Johannes Schindelin
2007-01-18 14:41 ` Alex Riesen
2007-01-18 14:49 ` Johannes Schindelin
2007-01-18 14:53 ` Alex Riesen
2007-01-18 15:16 ` Johannes Schindelin
2007-01-18 15:37 ` Alex Riesen
2007-01-18 15:42 ` Josh Boyer
2007-01-18 20:03 ` Johannes Schindelin
2007-01-18 20:12 ` Josh Boyer
2007-01-18 15:26 ` Shawn O. Pearce
2007-01-18 15:52 ` Alex Riesen
2007-01-18 19:29 ` Steven Grimm
2007-01-18 19:57 ` Johannes Schindelin
2007-01-18 16:09 ` Johannes Sixt
2007-01-19 10:11 ` Jakub Narebski
2007-01-18 15:42 ` Shawn O. Pearce [this message]
2007-01-18 16:05 ` Alex Riesen
2007-01-18 16:29 ` Andreas Ericsson
2007-01-18 16:51 ` Shawn O. Pearce
2007-01-18 17:03 ` Andreas Ericsson
2007-01-18 19:30 ` Martin Langhoff
2007-01-18 19:19 ` Martin Langhoff
2007-01-18 12:40 ` Andreas Ericsson
2007-01-18 15:10 ` Lukas Sandström
2007-01-18 15:29 ` Brian Gernhardt
2007-01-18 9:57 ` Alexandre Julliard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070118154257.GC15428@spearce.org \
--to=spearce@spearce.org \
--cc=davidk@lysator.liu.se \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=jwboyer@gmail.com \
--cc=raa.lkml@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.