git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: git@vger.kernel.org, Sven Verdoolaege <skimo@kotnet.org>
Subject: Re: git-filter-branch exits early
Date: Tue, 10 Jul 2007 22:57:44 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0707102222430.4047@racer.site> (raw)
In-Reply-To: <20070710205202.GA3212@steel.home>

Hi,

On Tue, 10 Jul 2007, Alex Riesen wrote:

> I have a Debian system where git-filter-branch exits immediately after
> "unset CDPATH" in git-sh-setup (the command exits with 1, as CDPATH is
> not defined). The system still has bash-2.05a.
> 
> git-filter-branch has "set -e", which is why the script finishes
> prematurely. If this is not really needed, maybe it can be removed?
> 
> I'll see if the system can be upgraded, but I suspect someone can get
> a similar problem.

I do not really understand why "unset CDPATH" should trigger an error.  I 
guess that this is one of the nice braindamages in dash, right?

Anyway, "set -e" was one thing I wanted to fix.  But I'm not sure I want 
to work on filter-branch now, what with skimo (possibly? hopefully?) 
working on my wishlist for rewrite-commits.  If rewrite-commits gets the 
features I wished for, IMHO filter-branch is obsolete.

Using rewrite-commits would have a couple of advantages:

- the name is much better,

- since we have reflogs enabled by default now, there is really no good 
  reason why you should have to copy the rewritten branches back to their 
  original name (we would need a way to redirect that, though, for 
  example for subdirectory filters),

- it is faster,

- since it is a C program, it should be more stable, eventually, than a 
  shell script, where you have to work around limitations all the time,

- with the trick I described in the mail to skimo, you can have 
  convenience functions (think "map") in the commit filter, too,

- and it would be less work for me.

Your case is a really good illustration for why C is a better language 
than shell in the long run.

Oh, BTW, if the index filter gets the current (original) commit SHA1 as an 
environment variable, like it does in filter-branch, it can act as a 
the first half of a subdirectory filter:

	--index-filter "git read-tree $COMMIT_SHA1:sub/directory/"

The second half of it is to add "-- sub/directory/" to the command line.

Ciao,
Dscho

  reply	other threads:[~2007-07-10 22:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-10 20:52 git-filter-branch exits early Alex Riesen
2007-07-10 21:57 ` Johannes Schindelin [this message]
2007-07-11  6:02   ` Alex Riesen
2007-07-11  7:55   ` Sven Verdoolaege
2007-07-18 13:17 ` [PATCH] filter-branch: get rid of "set -e" Johannes Schindelin
2007-07-18 13:27   ` David Kastrup
2007-07-18 14:05     ` 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=Pine.LNX.4.64.0707102222430.4047@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=raa.lkml@gmail.com \
    --cc=skimo@kotnet.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).