git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: linux@horizon.com
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH/RFC] filter-branch: support skipping of commits more easily
Date: Fri, 8 Jun 2007 06:12:17 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0706080605500.4059@racer.site> (raw)
In-Reply-To: <20070608021157.18066.qmail@science.horizon.com>

Hi,

On Fri, 7 Jun 2007, linux@horizon.com wrote:

> > I think that is fine; in effect, by saying "skip" B, you are
> > squashing B-C into C'.
> > 
> > Does this mean that, given
> > 
> >           C---D---E
> >          /   /
> >         A---B
> > 
> > and if commit-filter says "skip" on D, the written history would
> > look like this?
> > 
> >           C'------E'
> >          /       /
> >         A'--B'--'
> > 
> > The new commit E' would become an evil merge that has difference
> > between D and E in the original history?
> > 
> > I am not objecting; just trying to get a mental picture.
> 
> I think, for compatibility with the existing git path limiter,
> it should delete D from the history only if:
> 1) Told to skip D, and
> 2) Told to skip B or C (or both).
> 
> So you could get A--B--E' or A--C--E' or even A--E', but D would only
> be deleted if it wasn't needed as a merge marker.
> 
> That's probably a little more complex to implement, but it feels like
> The Right Thing.

... but if that script should do that, the name "filter"-branch was a 
misnomer.

It filters the _branch_. In the sense that a branch is one or more perls 
of commits, uniting in the tip of that branch.

If you want to skip a commit, that is fine. But a commit is _not_ a patch, 
no sir. It is a revision.

The fact that we actually are able to extract nice patches from any patch 
series, does not mean that the revisions are actually only deltas with 
regard to the previous commit. To the contrary: we actually allow -- and 
encourage -- git-diff between different revisions, be they on the same 
branch or not. That alone should tell everybody that a revision is a 
revision is a revision, and _not_ a delta.

So, when you filter commits, you should not expect a certain _patch_ to be 
skipped when you say "skip" (or maybe "squash", which I actually like 
better, because it is as unambiguous as you get it), but a _commit_ (AKA 
revision) to be skipped.

Ciao,
Dscho

  reply	other threads:[~2007-06-08  5:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-08  2:11 [PATCH/RFC] filter-branch: support skipping of commits more easily linux
2007-06-08  5:12 ` Johannes Schindelin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-06-07 23:59 Johannes Schindelin
2007-06-08  0:42 ` Junio C Hamano
2007-06-08  4:17   ` Johannes Schindelin
2007-06-08  6:40     ` Junio C Hamano

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.0706080605500.4059@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=linux@horizon.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).