git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Rhodes, Kate" <masukomi@gmail.com>,
	git@vger.kernel.org
Subject: Re: ambiguous git-log date and timestamp syntax
Date: Sun, 2 Mar 2008 10:40:54 +0100	[thread overview]
Message-ID: <200803021040.55252.jnareb@gmail.com> (raw)
In-Reply-To: <alpine.LSU.1.00.0803020240390.22527@racer.site>

On Sun, 2 Mar 2008, Johannes Schindelin wrote:
> On Sat, 1 Mar 2008, Jakub Narebski wrote:
> 
>> BTW. Git has few other such "reimplementing the wheel" things, like 
>> strbuf, or ALLOC_GROW, or it's own parseopt. I guess main reasons are to 
>> avoid adding yet another dependency, and that existing solutions doesn't 
>> fill all git needs.
> 
> Or that the existing wheels are quadratic wheels, and flat.

That's what I meant by "existing solutions don't fill all git needs".

> Just look at our own parse-options.[ch].  It is _still_ smaller and less 
> difficult to read than GNU getopt.  Yet, it is also much more powerful and 
> easier to use.

I meant here not only 'getopt', but also 'argp' (from libc), or 'popt'
library (used by rpm).

> Likewise, strbuf compares to Bstring, for example (although you might say 
> that Bstring is more powerful, but it comes at a price: it clutters the 
> namespace, and is not as performant as strbuf).

I vaguely recall something of discussion about this.

> ALLOC_GROW() is so small as to not merit any third-party dependency.  

True.

> Also, I'd like to caution that depending on 3rd-party libraries is not 
> always easy: just think about how much pain we suffer from the 
> ever-changing asciidoc package, and the problems wit docbook xsl.

I was rather thinking about something like git "dependency" on libXdiff,
namely having it embedded in git sources, perhaps as submodule, with git
specific improvements / changes / simplifications.


I wonder if it would be worthwhile to extract all those useful codelets
(mini libraries) like approxidate, strbuf, parseopt, ALLOC_GROW, 
list utils, etc. into separate micro-projects, to be able to be used
by other projects, for *them* not to have to reimplement the wheel.

Just a thought...
-- 
Jakub Narebski
Poland

  reply	other threads:[~2008-03-02  9:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-01 16:15 ambiguous git-log date and timestamp syntax Rhodes, Kate
2008-03-01 17:10 ` Jakub Narebski
2008-03-01 21:46   ` Linus Torvalds
2008-03-01 22:26     ` Jakub Narebski
2008-03-02  2:44       ` Johannes Schindelin
2008-03-02  9:40         ` Jakub Narebski [this message]
2008-03-02 14:40           ` Johannes Schindelin
2008-03-02  7:09       ` Florian Weimer
2008-03-02 14:11 ` [PATCH] Documentation: Remove --{min,max}-age option from git-log(1) 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=200803021040.55252.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=masukomi@gmail.com \
    --cc=torvalds@linux-foundation.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).