Re: [JGIT PATCH 1/1] jgit: create a tag command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike Ralphson <mike.ralphson@xxxxxxxxx> wrote:
> 2008/7/11 Shawn O. Pearce <spearce@xxxxxxxxxxx>:
> > Mike Ralphson <mike.ralphson@xxxxxxxxx> wrote:
> >>
> >> Loving the make_jgit stuff.
> >
> > So making jgit a single stand-alone, portable shell script for
> > command line usage was a good idea?  ;-)
> 
> It certainly seems so to me. It's a nice quick way of seeing what's
> implemented (I was toying with adding a jgit help command which would
> reflect over the TextBuiltins).

Yea, sadly our builtins don't register themselves into a table so its
a bit difficult to enumerate them at this time.  But it probably would
not be a difficult thing to change at all, and since we don't have a
lot of them yet it wouldn't be that much work to do the conversion.
 
> I'm not sure which if any platforms would eventually be better off
> with a commandline jgit than trying to port c-git though.

Not all platforms can compile c git, e.g. they are missing a
c compiler, but have a JRE handy.  Odd, I know, but sometimes
that's how it goes.  Or maybe you have a JRE handy, and want to
just download the single stand-alone jgit jar to get some sort of a
basic git implementation available, so you can clone and build the
real thing direct from Junio's sources.

Or maybe you are using a transport (Amazon S3) that C Git just
doesn't support.  :-)

> > I think we are at the point where we need to either write a
> > #@!*(!@(! command line option parser, import one, or stop writing
> > command line programs.  I would certainly appreciate any opinion
> > you might have on the matter.
> 
> a) is a distraction, c) is a backwards step, so maybe b) wins.

I don't disagree, I thought the very same thing myself.
 
> I don't know what the state of the art of Java option parsers is but
> there is a port of GNU getopt [1] which might drop in quite easily.

So I looked at GNU getopt and its at least smaller than Apache
Commons, and doesn't have this damned-if-you-do, damned-if-you-do
version selection choice they offer their end-users.  But it really
makes building something like an automatic --help difficult if not
impossible, and certainly makes handling numeric vs. ObjectId vs.
String vs. File arguments annoying.

I'd almost rather just do a).  It wouldn't take long to get something
small rolled out and working.  We don't need to support every goddamn
weird syntax that C git supports for backward compatability reasons.

> PS apologies for the patch format, I'm stuck with Outlook or gmail,
> and a recalcitrant firewall for the moment.

Some people are terrified of that system of tubes.  I feel for you.
Day-job is that way.  :-(
 
> [1] http://www.urbanophile.com/arenn/hacking/download.html

-- 
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux