Re: git filter-branch re-write history over a range of commits did notwork

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 28, 2019, 09:57 UTC
Message-ID: <nycvar.QRO.7.76.6.1905281154390.44@tvgsbejvaqbjf.bet>
In-Reply-To: <3cf99e80-98aa-639b-ac9d-a882da349fc8@iee.org>

Hi,

On Tue, 28 May 2019, Philip Oakley wrote:

Show 26 quoted lines

> On 28/05/2019 08:10, LU Chuck wrote:
> [snip]
> > > 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 ...?
> https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-Theem82308203emthree-dotSymmetricDifferenceNotation
> >           "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)

From https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-Theem82308203emthree-dotSymmetricDifferenceNotation:

	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 out.

Ciao, Johannes