From: Jeff King <peff@peff.net>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Jakub Narebski <jnareb@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Cross-Platform Version Control (was: Eric Sink's blog - notes on git, dscms and a "whole product" approach)
Date: Wed, 29 Apr 2009 03:21:05 -0400 [thread overview]
Message-ID: <20090429072105.GD22593@coredump.intra.peff.net> (raw)
In-Reply-To: <46a038f90904282355g43bf0cv909905f6028f054f@mail.gmail.com>
On Wed, Apr 29, 2009 at 08:55:29AM +0200, Martin Langhoff wrote:
> So from Eric's perspective, it is worthwhile to work on all those
> issues, and get the right for the end user -- support things we don't
> like, offer foolproof catches and warnings that prevent the user from
> shooting their lovely toes off to mars, etc.
I read a few of his blog postings. He kept complaining about the
features of git that I like the most. :)
So one thing I took away from it is that there probably isn't _one_
interface that works for everybody. I can see his arguments about how
"add -p" can be dangerous, and how history rewriting can be dangerous.
So for some users, blocking those features makes sense.
But for other users (myself included), those are critical features that
make me _way_ more productive. And I manage the risk that comes from
using them as part of my workflow, and it isn't a problem in practice.
While part of me is happy that cogito is now dead (not because I didn't
think it was good, but because having two sets of tools just seemed to
create maintenance and staleness headaches), I do sometimes wonder if we
would be better off with several "from scratch" git interfaces based
around the plumbing (or even a C library). And I don't just mean simple
wrappers around git commands, but whole new interfaces which make
decisions like "no history rewriting at all", and try to provide a safer
interface based on that.
Of course, _I_ wouldn't want to use such an interface. But in theory I
could seamlessly interoperate with people who did.
-Peff
next prev parent reply other threads:[~2009-04-29 7:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 8:55 Eric Sink's blog - notes on git, dscms and a "whole product" approach Martin Langhoff
2009-04-28 11:24 ` Cross-Platform Version Control (was: Eric Sink's blog - notes on git, dscms and a "whole product" approach) Jakub Narebski
2009-04-28 21:00 ` Robin Rosenberg
2009-04-29 6:55 ` Martin Langhoff
2009-04-29 7:21 ` Jeff King [this message]
2009-04-29 20:05 ` Markus Heidelberg
2009-04-29 7:52 ` Cross-Platform Version Control Jakub Narebski
2009-04-29 8:25 ` Martin Langhoff
2009-04-28 18:16 ` Eric Sink's blog - notes on git, dscms and a "whole product" approach Jakub Narebski
2009-04-29 7:54 ` Sitaram Chamarty
2009-04-30 12:17 ` Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach) Jakub Narebski
2009-04-30 12:56 ` Michael Witten
2009-04-30 15:28 ` Why Git is so fast Jakub Narebski
2009-04-30 18:52 ` Shawn O. Pearce
2009-04-30 20:36 ` Kjetil Barvik
2009-04-30 20:40 ` Shawn O. Pearce
2009-04-30 21:36 ` Kjetil Barvik
2009-05-01 0:23 ` Steven Noonan
2009-05-01 1:25 ` James Pickens
2009-05-01 9:19 ` Kjetil Barvik
2009-05-01 9:34 ` Mike Hommey
2009-05-01 9:42 ` Kjetil Barvik
2009-05-01 17:42 ` Tony Finch
2009-05-01 5:24 ` Dmitry Potapov
2009-05-01 9:42 ` Mike Hommey
2009-05-01 10:46 ` Dmitry Potapov
2009-04-30 18:43 ` Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach) Shawn O. Pearce
2009-04-30 14:22 ` Jeff King
2009-05-01 18:43 ` Linus Torvalds
2009-05-01 19:08 ` Jeff King
2009-05-01 19:13 ` david
2009-05-01 19:32 ` Nicolas Pitre
2009-05-01 21:17 ` Daniel Barkalow
2009-05-01 21:37 ` Linus Torvalds
2009-05-01 22:11 ` david
2009-04-30 18:56 ` Nicolas Pitre
2009-04-30 19:16 ` Alex Riesen
2009-05-04 8:01 ` Why Git is so fast Andreas Ericsson
2009-04-30 19:33 ` Jakub Narebski
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=20090429072105.GD22593@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=martin.langhoff@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).