From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Johannes Sixt <J.Sixt@eudaptics.com>
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 20:52:08 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0707242047400.14781@racer.site> (raw)
In-Reply-To: <46A614CE.597C7130@eudaptics.com>
Hi,
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> >
> > > Johannes Schindelin wrote:
> > >
> > > > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > > >
> > > > > 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.
> >
> > So you think we have to say something like
> >
> > git rev-list "$ref" $negatives | grep "$ref" > /dev/null || continue
> >
> > ?
>
> No, doesn't help either.
>
> We are talking about a case where there is more than one positive ref.
> We need not consider the -- sub/ case - it makes things just even more
> complicated. There are two different rev ranges to be considered:
>
> # (1) candidate range to be rewritten
> $ git rev-list "$@"
>
> # (2) test if positive ref is in candidate range
> $ git rev-list $ref $negatives
Okay, but with out any subdirs,
git rev-list "$@" | grep $(git rev-parse "$ref") > /dev/null || continue
should do exactly what we want. But in that case, we could just use the
generated list ../revs to grep for the positive refs.
Darn, this _is_ getting complicated.
Ciao,
Dscho
next prev parent reply other threads:[~2007-07-24 19:52 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
2007-07-24 14:21 ` Johannes Schindelin
2007-07-24 15:03 ` Johannes Sixt
2007-07-24 19:52 ` Johannes Schindelin [this message]
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=Pine.LNX.4.64.0707242047400.14781@racer.site \
--to=johannes.schindelin@gmx.de \
--cc=J.Sixt@eudaptics.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
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).