git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Reece Dunn" <msclrhd@googlemail.com>
To: "David Tweed" <david.tweed@gmail.com>,
	"Theodore Tso" <tytso@mit.edu>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: [PATCH] Make "git reset" a builtin. (incomplete)
Date: Thu, 23 Aug 2007 12:25:47 +0100	[thread overview]
Message-ID: <3f4fd2640708230425h3cb793fbg17b09f561ede07ae@mail.gmail.com> (raw)
In-Reply-To: <e1dab3980708230355x1d5d2febw6814e8f24d745ddd@mail.gmail.com>

On 23/08/07, David Tweed <david.tweed@gmail.com> wrote:
> On 8/23/07, Theodore Tso <tytso@mit.edu> wrote:
> > (To accomodate those Windows users who for some silly reason refuse to
> > install Cygwin, bash, and perl on their Windows development box.  :-)
>
> I personally don't care exactly what's used implementing git on non-unix
> platforms, but I get nervous as more and more "layers" are added so
> it becomes more and more difficult to figure which layer a user problem
> is occurring at. If it looks to difficult to "help out with" issues on Windows,
> that would be a big enough reason for me not to use git on such projects.

This is one of the reasons I _suggested_ C# for the _Windows_
porcelian. That way, you have the git plumbing written in C, and the
porcelain is implemented in supported tools for the target platform.

I don't mind what the porcelain is written in. However, standardizing
on a single language improves the ability to target more people,
especially as a shell, perl and python are not supported out of the
box on Windows like they are on posix systems. This is important for
some Windows developers and setting up build machines and the like
(most, if not all, Windows users expect each application to be
independant of anything else). It also reduces the surface area in
which problems can occur.

Therefore, we come back to porting the stable scripts to "pure" C.
Doing this for git-rebase _helped_ the Windows port. With a purely C
implementation you have fewer places where problems can arise and
platform issues can be dealt with in a unified way, instead of
duplicating them in each script.

This does not prevent new commands from being prototyped in a
scripting language. Nor does it prevent the user from running the
commands in their own shell/perl/python scripts. It would limit the
"bleeding edge" commands to posix platforms (including cygwin), until
they are supported natively, but that would not hinder adoption of git
on Windows platforms.

- Reece

  parent reply	other threads:[~2007-08-23 11:26 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-22 12:48 [PATCH] Make "git reset" a builtin. (incomplete) Carlos Rica
2007-08-22 13:00 ` David Kastrup
2007-08-22 13:37   ` Andreas Ericsson
2007-08-22 14:29     ` David Kastrup
2007-08-22 14:49       ` Mike Hommey
2007-08-22 15:02         ` Chris Shoemaker
2007-08-22 15:41           ` David Kastrup
2007-08-22 16:07       ` Nicolas Pitre
2007-08-22 16:51         ` Johannes Schindelin
2007-08-22 17:17           ` David Kastrup
2007-08-22 19:05             ` Linus Torvalds
2007-08-22 19:36               ` David Kastrup
2007-08-22 19:58                 ` Linus Torvalds
2007-08-22 22:25                   ` David Kastrup
2007-08-22 23:10                     ` Linus Torvalds
2007-08-22 23:39                       ` David Kastrup
2007-08-23  1:30                         ` Linus Torvalds
2007-08-23  0:24                     ` Wincent Colaiuta
2007-08-23  1:15               ` Nicolas Pitre
2007-08-23  1:40                 ` Jon Smirl
2007-08-23  3:23                 ` Linus Torvalds
2007-08-23  4:21                   ` Junio C Hamano
2007-08-23  9:15                   ` Johannes Schindelin
2007-08-22 21:34             ` Reece Dunn
2007-08-23  9:10               ` Johannes Schindelin
2007-08-23 10:20                 ` Theodore Tso
2007-08-23 10:31                   ` Johannes Schindelin
2007-08-23 10:55                   ` David Tweed
2007-08-23 11:24                     ` Theodore Tso
2007-08-23 11:35                       ` Johannes Schindelin
2007-08-23 16:30                       ` Jon Smirl
2007-08-23 11:25                     ` Reece Dunn [this message]
2007-08-23 20:26             ` Alex Riesen
2007-08-23 21:14               ` David Kastrup
2007-08-23 21:33                 ` Alex Riesen
2007-08-23 22:05                   ` David Kastrup
2007-08-22 17:21           ` Nicolas Pitre
2007-08-23  9:55             ` Johannes Schindelin
2007-08-23 15:19               ` Nicolas Pitre
2007-08-22 21:19           ` Reece Dunn
2007-08-23  9:05             ` Johannes Schindelin
2007-08-23 18:40             ` Robin Rosenberg
2007-08-23  2:05       ` Nguyen Thai Ngoc Duy
2007-08-22 13:42   ` Matthieu Moy
2007-08-22 22:28     ` David Kastrup
2007-08-22 14:27   ` Andy Parkins
2007-08-22 14:57 ` Johannes Sixt
2007-08-22 16:20 ` Alex Riesen
2007-08-23 11:14 ` Johannes Schindelin

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=3f4fd2640708230425h3cb793fbg17b09f561ede07ae@mail.gmail.com \
    --to=msclrhd@googlemail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=david.tweed@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).