From: Johannes Sixt <J.Sixt@eudaptics•com>
To: Johannes Schindelin <Johannes.Schindelin@gmx•de>
Cc: gitster@pobox•com, git@vger•kernel.org
Subject: Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
Date: Tue, 24 Jul 2007 16:08:43 +0200 [thread overview]
Message-ID: <46A607EB.BA31D7C5@eudaptics.com> (raw)
In-Reply-To: Pine.LNX.4.64.0707241435290.14781@racer.site
Johannes Schindelin wrote:
> On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > This worked:
> >
> > negatives=`git rev-parse --revs-only "$@" | while read line
> > do
> > case "$line" in
> > $_x40) ;;
> > *) echo "$line";;
> > esac
> > done`
> >
> > i.e. the closing parenthesis in the case arms together with the opening
> > $( made for a syntax error. The --revs-only did not hurt in my tests,
> > but you may have other reasons to remove it.
>
> Funny. AFAIR something similar worked here, all the time. But I believe
> you... you're on MinGW, right?
No. filter-branch is a shell script. I don't have time to waste ;)
It happens in bash 2.05b on Linux.
> > But there's another problem. Consider this history:
> >
> > ---X--o--M <- master
> > \
> > ...-o-...-o <- topic
> >
> > Then this (rather contrieved) command:
> >
> > $ git-filter-branch -n $n master topic --not X
> >
> > If $n is small enough so that M is never rewritten, then
> >
> > git rev-list -1 "$ref" $negatives
> >
> > still expands to non-empty even for 'master' (= M), which then
> > incorrectly ends up in "$tempdir"/heads.
>
> Aaargh! Of course! Since I have to add --topo-order at the end.
> Otherwise it makes no sense.
No, that was no my point: In my example above, if n=1, `git rev-list -1
"$ref" $negatives` evaluates to
$ git rev-list -1 "master" -n 1 ^X
which returns M, even though M is not going to be rewritten.
--topo-order changes nothing. The problem is that the -n is a relative
restriction. --since is turned into --max-age, which is absolute,
therefore, the test works as expected with --since.
> > I think the decision whether a positive ref should be rewritten should
> > be postponed until the rewrite has completed. Because then we know for
> > certain which revs were treated and can pick the matching refs. We only
> > lose the check for the error "Which ref do you want to rewrite?"
>
> No, that is not enough:
>
> A - B - C
>
> B touches the subdirectory sub/.
>
> git filter-branch C -- sub/
>
> will not rewrite C.
Fair enough.
-- Hannes
next prev parent reply other threads:[~2007-07-24 14:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-23 17:34 [PATCH] filter-branch: Big syntax change; support rewriting multiple refs Johannes Schindelin
2007-07-24 5:35 ` Junio C Hamano
2007-07-24 9:10 ` Johannes Schindelin
2007-07-24 9:27 ` [PATCH] filter-branch: Big syntax change; support rewriting multiplerefs Johannes Sixt
2007-07-24 10:36 ` [PATCH] filter-branch: when dwim'ing a ref, only allow heads and tags Johannes Schindelin
2007-07-24 11:04 ` [PATCH] filter-branch: when dwim'ing a ref, only allow heads andtags Johannes Sixt
2007-07-24 11:20 ` Johannes Schindelin
2007-07-24 11:27 ` [PATCH] filter-branch: when dwim'ing a ref, only allow heads and tags Johannes Schindelin
2007-07-24 11:06 ` [PATCH] filter-branch: rewrite only refs which were not excluded by the options Johannes Schindelin
2007-07-24 11:23 ` [PATCH] filter-branch: rewrite only refs which were not excluded bythe options Johannes Sixt
2007-07-24 11:33 ` Johannes Schindelin
2007-07-24 13:32 ` [PATCH] filter-branch: rewrite only refs which were not excludedbythe options Johannes Sixt
2007-07-24 13:41 ` Johannes Schindelin
2007-07-24 14:08 ` Johannes Sixt [this message]
2007-07-24 14:21 ` Johannes Schindelin
2007-07-24 15:03 ` Johannes Sixt
2007-07-24 19:52 ` Johannes Schindelin
2007-07-24 13:42 ` [REVISED PATCH] filter-branch: rewrite only unexcluded refs Johannes Schindelin
2007-07-24 13:33 ` [PATCH] filter-branch: rewrite only refs which were not excludedbythe options Johannes Sixt
2007-07-24 13:46 ` 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=46A607EB.BA31D7C5@eudaptics.com \
--to=j.sixt@eudaptics$(echo .)com \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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