Re: git filter-branch re-write history over a range of commits did notwork
- Date: Tue, 28 May 2019 11:57:36 +0200 (CEST)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: git filter-branch re-write history over a range of commits did notwork
On Tue, 28 May 2019, Philip Oakley wrote:
> On 28/05/2019 08:10, LU Chuck wrote:
> > > Copying and pasting examples literally is dangerous. You should know what
> > > you
> > > are doing.
> > >
> > > "..." is a revision range that computes the mergebase between HEAD and
> > > HEAD,
> > > which is (surprise!) HEAD, and then includes the two end points, but
> > > excludes
> > > everything below the mergebase. So, the revision specification that your
> > > command ends up with is
> > >
> > > HEAD HEAD ^HEAD ^67d9d9 f70bf4
> > >
> > > Which is empty if f70bf4 is an ancestor of HEAD.
> > [LU Chuck] Sorry, I can't understand this part, did you have an
> > documentation about the explanation for ...?
> > "computes the mergebase between HEAD and HEAD" I have no idea
> > about this. And you also talked about mergebase, but in my
> > situation, there is only one branch with 5 commits. I did not have
> > a mergebase.
> > You can check the detail description below.
> When there is no specific revisions around the three dots then HEAD is assumed
> (to save typing)
The ... (three-dot) Symmetric Difference Notation
A similar notation r1...r2 is called symmetric difference of r1
and r2 and is defined as r1 r2 --not $(git merge-base --all r1
r2). It is the set of commits that are reachable from either one
of r1 (left side) or r2 (right side) but not from both.
Most importantly, the next paragraph states:
In these two shorthand notations, you can omit one end and let it
default to HEAD.
What it does *not* say is that you can leave out both ends, in which case
it becomes the non-sensical short form of `HEAD...HEAD`, as Hannes pointed