git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
To: "David Kastrup" <dak@gnu.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Make "git reset" a builtin. (incomplete)
Date: Thu, 23 Aug 2007 09:05:37 +0700	[thread overview]
Message-ID: <fcaeb9bf0708221905p617c3689m89a838fdcd97dedb@mail.gmail.com> (raw)
In-Reply-To: <864pirej6w.fsf@lola.quinscape.zz>

On 8/22/07, David Kastrup <dak@gnu.org> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > David Kastrup wrote:
> >> Carlos Rica <jasampler@gmail.com> writes:
> >>
> >>> This is the first version of the program "builtin-reset.c",
> >>> intended for replacing the script "git-reset.sh".
> >>>
> >>> The --mixed option with -- paths is not implemented yet.
> >>>
> >>> The tests I made for it are not finished so they are not included,
> >>> but it seems to pass the rest of the test suite.
> >>
> >> Could you be so kind as to give a one-sentence summary what the
> >> benefits over using a shell script would be?
> >
> > One word: Portability.
> >
> > There's a plethora of various shell syntaxes. Discerning what's
> > correct shell and what's a bash'ism that may or may not be posixly
> > correct (but perhaps not supported on a multitude of out-of-the-box
> > solaris system) has so far taken almost as much time as convincing
> > newcomers to git that there really is no point in tracking file
> > renames explicitly.
> >
> > Otoh, the list of large and renowned projects that have shunned git
> > for its weak windows support grows longer, meaning we potentially
> > lose competent programmers simply because they're forced to use
> > something else.
>
> The problem I see is that C sucks really really bad as a scripting
> language, and tying together plumbing functionality into porcelain is
> one of the most powerful, flexible and hack-friendly features of git.
> Deprecating scripts is making git more opaque.
>
> Personally, I would prefer an approach of using an embedded script
> interpreter: then language incompatibilities become a non-issue.
> git-busybox sounded like a great idea for portability.

Although I have never tested git-box (git-busybox) under Linux, I
believe it would work well because all Unix specific code remains the
same as in busybox. Making git-box part of git would increase git
binary size by ~200kb IIRC.
-- 
Duy

  parent reply	other threads:[~2007-08-23  2:06 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
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 [this message]
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=fcaeb9bf0708221905p617c3689m89a838fdcd97dedb@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    /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).