git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: David Rientjes <rientjes@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] cleans up builtin-mv
Date: Fri, 18 Aug 2006 11:51:47 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.63.0608181137000.28360@wbgn013.biozentrum.uni-wuerzburg.de> (raw)
In-Reply-To: <Pine.LNX.4.63.0608172301520.25827@chino.corp.google.com>

Hi,

On Thu, 17 Aug 2006, David Rientjes wrote:

> On Thu, 17 Aug 2006, David Rientjes wrote:
> 
> > Cleans up builtin-mv by removing a needless check of source's length, 
> > redefinition of source's length, and misuse of strlen call that was 
> > already assigned.
> > 
> 
> I'm not sure when this command had been added to the tree

Tip of the day: "git log builtin-mv.c"

> because it definitely was not included six months ago in a git tree I 
> use everyday.  It seems to me like this would more appropriately be 
> handled by a simple shell script

Nooooooo!

First, it _was_ a perl script, which you probably could find out by 
checking your old git.

Second, it was rewritten to use Git.pm, and because _that_ did not work, 
git-mv was rewritten as a builtin.

> that would be much simpler to implement and could not possibly be slower 
> than this implementation.

Not slower? I beg to differ, admitting it is only a few percent. But your 
statement is obviously uncorrect.

As for the "simpler to implement": "harder to port" comes into mind. And 
do not try to argue that everybody and his dog could switch to Linux.

> This patch is a small fraction of what could be changed in this 
> implementation and I don't doubt it will undergo a complete rewrite in 
> the future.

Well, the patch has an improvement factor of almost none. I actually read 
the patch, and asked myself: why would anybody fix a non-problem?

> I think the problems with it have compounded on top of itself over time 
> which doesn't make a lot of sense since it appears to be a relatively 
> new addition.
> 
> For example:
> 	(length = strlen(source[i])) >= 0

Yes. Taken out of context, this sure sounds silly.

What you cleverly did not mention: It was inside a

	if (!bad &&
		(length = strlen(source[i])) >= 0 &&
		!strncmp(destination[i], source[i], length) &&
		(destination[i][length] == 0 || destination[i][length] == '/'))

construct. So, we assign the "length" variable only if we have to. And the 
">= 0" trick is a common one. I could have done

		!strncmp(destination[i], source[i], (length = strlen(source[i])))

but even I find that ugly.
		
> was _completely_ unnecessary since the previous instruction was a call to 
> lstat(source[i], ...) which would return ENOENT if source[i] was empty.  

Clarified enough?

> strlen(source[i]) was assigned to a variable later in the function, this 
> time called "len" instead.

Only if source[i] is a directory. So again, we only do it when we need to.

> This code is _utterly_ unsatisfactory.

I disagree.

What is unsatisfactory to me is that I expected some performance 
improvements from one of your earlier mails, and I see patches which 
rearrange working code. This _can_ result in performance improvements, but 
in these cases, no, it doesn't.

Having said that, I do not have anything against the patch being applied, 
but if I see more of these i-would-like-the-cupboard-here-not-there 
patches, I will just not review them any more.

Ciao,
Dscho

  reply	other threads:[~2006-08-18  9:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-18  5:59 [PATCH] cleans up builtin-mv David Rientjes
2006-08-18  6:12 ` David Rientjes
2006-08-18  9:51   ` Johannes Schindelin [this message]
2006-08-18 17:07     ` David Rientjes
2006-08-18 18:35       ` Josef Weidendorfer
2006-08-18 19:01         ` David Rientjes
2006-08-18 19:33     ` Junio C Hamano
2006-08-19  1:26       ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.63.0608181137000.28360@wbgn013.biozentrum.uni-wuerzburg.de \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=rientjes@google.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).