Hi All,

As many know already, due to the DMCA takedown notice for VST-related
code that was in Csound, we had to move quickly to rewrite the git
history to remove any mention of VST-related code (24 hrs). After that
happened, and because we had rewritten git histories, merge commits
based on the older histories were done such that we now have
triplicate commits for a large part of the history for the develop
branch (master branch is clean).

We have spent a fair amount of time looking at strategies but the work
looks to require a large manual effort to go through and cherry pick
commits.  This is to ensure a cleaned up develop branch will merge
cleanly to master.

I am starting to look into this again and found the following command
to be useful:

 git log --oneline --ancestry-path 652633..HEAD

which shows a series of commits that descend from 6.11.0 up until the
HEAD of develop.  We can probably start from a later parent point to
just before the date of the DMCA-related changes.

I am currently investigating branch cleanup work in a forked Csound
repository under my user account on github.  I'll report anything I
find here.

Thanks, that's valuable information.  I'll do some experimentation
today with rebasing and cherry picking.  May take some time to get
through this.
On Tue, Aug 28, 2018 at 9:20 AM Felipe Sateler  wrote:
>
> I have a local repo with unclean history. This also has the benefit of having the old tags: the ones containing the vst code. I did the following:
>
> gitk 6.11.0..develop
>
> This gave me the history from the "old" 6.11.0 release to current develop. I could then pinpoint the first commit that merges both histories: 4a7ea2c7e6f91b4285ee393edd19d920a5ca5d03. There appears to be a second merge a bit later: either a3183704a2765f49b78124abb93704e8545814a9 or 54d13fee2e7450d3ef5066ffa2167f9073f66fdc , but I can't quite parse the commit graph from a quick look.
>
> There don't appear to be any more merges from the parallel histories after 54d13fee2e7450d3ef5066ffa2167f9073f66fdc
>
> Saludos
>
> On Tue, Aug 28, 2018 at 12:54 AM Steven Yi  wrote:
>>
>> Hi All,
>>
>> As many know already, due to the DMCA takedown notice for VST-related
>> code that was in Csound, we had to move quickly to rewrite the git
>> history to remove any mention of VST-related code (24 hrs). After that
>> happened, and because we had rewritten git histories, merge commits
>> based on the older histories were done such that we now have
>> triplicate commits for a large part of the history for the develop
>> branch (master branch is clean).
>>
>> We have spent a fair amount of time looking at strategies but the work
>> looks to require a large manual effort to go through and cherry pick
>> commits.  This is to ensure a cleaned up develop branch will merge
>> cleanly to master.
>>
>> I am starting to look into this again and found the following command
>> to be useful:
>>
>>  git log --oneline --ancestry-path 652633..HEAD
>>
>> which shows a series of commits that descend from 6.11.0 up until the
>> HEAD of develop.  We can probably start from a later parent point to
>> just before the date of the DMCA-related changes.
>>
>> I am currently investigating branch cleanup work in a forked Csound
>> repository under my user account on github.  I'll report anything I
>> find here.
>>
>> Steven
>
>
>
> --
>
> Saludos,

I had some time to look at this today and it looks to me that these
two commits are the ones with issues:

4a7ea2c7e6f91b4285ee393edd19d920a5ca5d03
78949276150d6358728692e63d2d7b905d5eb927

I looked at the other two reported by Felipe but didn't see issues
when I used git log --ancestry-path to find ancestors.

For the first commit, I tried:

git log --oneline --ancestry-path 652633..cc84b96
git log --oneline --ancestry-path 652633..89ca172

and found the first had no shared commits, so:

BAD:  parent cc84b961d6b45c03354b0c66e989217e025b3db3
GOOD: parent 89ca1728077f0ec8152a766ad7c63500b29a166c

I modified using:

git replace --edit 4a7ea2c7e6

and erasing the line with cc84b961d

and I got:

$ git rev-list --count HEAD
29931

Which seemed in the right direction.

To find the second commit, I used git bisect to go between the HEAD of
develop (bad) and 652633 (good). While bisecting, I used the 'git
rev-list --count HEAD' command to see if the number of commits was in
the 14k or 28k range and marked good/bad accordingly, ultimately
arriving at the second commit.

However, with the second commit, I tried something similar and found:

git log --oneline --ancestry-path 652633..e4ca0b12a

and found no shared commits.  But if I ran:

git replace --edit 7894927615

and removed the line with e4ca0b12a I still had 29K commits.


I'm not sure if my process is correct, but this seems like getting
closer.  If anyone else has time to look from here that'd be great as
this is tiring and my time at the moment is intermittent to look at
this.

On Tue, Aug 28, 2018 at 2:49 PM Felipe Sateler  wrote:
>
> Also, this stackoverflow answer might be helpful:
>
> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>
> On Tue, Aug 28, 2018 at 11:07 AM Steven Yi  wrote:
>>
>> Thanks, that's valuable information.  I'll do some experimentation
>> today with rebasing and cherry picking.  May take some time to get
>> through this.
>> On Tue, Aug 28, 2018 at 9:20 AM Felipe Sateler  wrote:
>> >
>> > I have a local repo with unclean history. This also has the benefit of having the old tags: the ones containing the vst code. I did the following:
>> >
>> > gitk 6.11.0..develop
>> >
>> > This gave me the history from the "old" 6.11.0 release to current develop. I could then pinpoint the first commit that merges both histories: 4a7ea2c7e6f91b4285ee393edd19d920a5ca5d03. There appears to be a second merge a bit later: either a3183704a2765f49b78124abb93704e8545814a9 or 54d13fee2e7450d3ef5066ffa2167f9073f66fdc , but I can't quite parse the commit graph from a quick look.
>> >
>> > There don't appear to be any more merges from the parallel histories after 54d13fee2e7450d3ef5066ffa2167f9073f66fdc
>> >
>> > Saludos
>> >
>> > On Tue, Aug 28, 2018 at 12:54 AM Steven Yi  wrote:
>> >>
>> >> Hi All,
>> >>
>> >> As many know already, due to the DMCA takedown notice for VST-related
>> >> code that was in Csound, we had to move quickly to rewrite the git
>> >> history to remove any mention of VST-related code (24 hrs). After that
>> >> happened, and because we had rewritten git histories, merge commits
>> >> based on the older histories were done such that we now have
>> >> triplicate commits for a large part of the history for the develop
>> >> branch (master branch is clean).
>> >>
>> >> We have spent a fair amount of time looking at strategies but the work
>> >> looks to require a large manual effort to go through and cherry pick
>> >> commits.  This is to ensure a cleaned up develop branch will merge
>> >> cleanly to master.
>> >>
>> >> I am starting to look into this again and found the following command
>> >> to be useful:
>> >>
>> >>  git log --oneline --ancestry-path 652633..HEAD
>> >>
>> >> which shows a series of commits that descend from 6.11.0 up until the
>> >> HEAD of develop.  We can probably start from a later parent point to
>> >> just before the date of the DMCA-related changes.
>> >>
>> >> I am currently investigating branch cleanup work in a forked Csound
>> >> repository under my user account on github.  I'll report anything I
>> >> find here.
>> >>
>> >> Steven
>> >
>> >
>> >
>> > --
>> >
>> > Saludos,
>> > Felipe Sateler
>
>
>
> --
>
> Saludos,

Hi Steven,

I started to look at this by reproducing your steps. I made a local branch (dev2) and tried the
commands there. I also tried (blindly) to remove the other commit in the second 
git replace command (git replace --edit 7894927615), with no change in commit numbers.

However, what worried me was that when I switched back to the develop branch, I had 
29k commits, which means that the edits I made were global (I did not expect that).

So now I am concerned that I will need to do a fresh checkout in order to carry on
working otherwise in my next commit these experiments will be pushed to remote.

Anyway, it’s just a word of warning for anyone working on this

best regards
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> 
> I had some time to look at this today and it looks to me that these
> two commits are the ones with issues:
> 
> 4a7ea2c7e6f91b4285ee393edd19d920a5ca5d03
> 78949276150d6358728692e63d2d7b905d5eb927
> 
> I looked at the other two reported by Felipe but didn't see issues
> when I used git log --ancestry-path to find ancestors.
> 
> For the first commit, I tried:
> 
> git log --oneline --ancestry-path 652633..cc84b96
> git log --oneline --ancestry-path 652633..89ca172
> 
> and found the first had no shared commits, so:
> 
> BAD:  parent cc84b961d6b45c03354b0c66e989217e025b3db3
> GOOD: parent 89ca1728077f0ec8152a766ad7c63500b29a166c
> 
> I modified using:
> 
> git replace --edit 4a7ea2c7e6
> 
> and erasing the line with cc84b961d
> 
> and I got:
> 
> $ git rev-list --count HEAD
> 29931
> 
> Which seemed in the right direction.
> 
> To find the second commit, I used git bisect to go between the HEAD of
> develop (bad) and 652633 (good). While bisecting, I used the 'git
> rev-list --count HEAD' command to see if the number of commits was in
> the 14k or 28k range and marked good/bad accordingly, ultimately
> arriving at the second commit.
> 
> However, with the second commit, I tried something similar and found:
> 
> git log --oneline --ancestry-path 652633..e4ca0b12a
> 
> and found no shared commits.  But if I ran:
> 
> git replace --edit 7894927615
> 
> and removed the line with e4ca0b12a I still had 29K commits.
> 
> 
> I'm not sure if my process is correct, but this seems like getting
> closer.  If anyone else has time to look from here that'd be great as
> this is tiring and my time at the moment is intermittent to look at
> this.
> 
> On Tue, Aug 28, 2018 at 2:49 PM Felipe Sateler  wrote:
>> 
>> Also, this stackoverflow answer might be helpful:
>> 
>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>> 
>> On Tue, Aug 28, 2018 at 11:07 AM Steven Yi  wrote:
>>> 
>>> Thanks, that's valuable information.  I'll do some experimentation
>>> today with rebasing and cherry picking.  May take some time to get
>>> through this.
>>> On Tue, Aug 28, 2018 at 9:20 AM Felipe Sateler  wrote:
>>>> 
>>>> I have a local repo with unclean history. This also has the benefit of having the old tags: the ones containing the vst code. I did the following:
>>>> 
>>>> gitk 6.11.0..develop
>>>> 
>>>> This gave me the history from the "old" 6.11.0 release to current develop. I could then pinpoint the first commit that merges both histories: 4a7ea2c7e6f91b4285ee393edd19d920a5ca5d03. There appears to be a second merge a bit later: either a3183704a2765f49b78124abb93704e8545814a9 or 54d13fee2e7450d3ef5066ffa2167f9073f66fdc , but I can't quite parse the commit graph from a quick look.
>>>> 
>>>> There don't appear to be any more merges from the parallel histories after 54d13fee2e7450d3ef5066ffa2167f9073f66fdc
>>>> 
>>>> Saludos
>>>> 
>>>> On Tue, Aug 28, 2018 at 12:54 AM Steven Yi  wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> As many know already, due to the DMCA takedown notice for VST-related
>>>>> code that was in Csound, we had to move quickly to rewrite the git
>>>>> history to remove any mention of VST-related code (24 hrs). After that
>>>>> happened, and because we had rewritten git histories, merge commits
>>>>> based on the older histories were done such that we now have
>>>>> triplicate commits for a large part of the history for the develop
>>>>> branch (master branch is clean).
>>>>> 
>>>>> We have spent a fair amount of time looking at strategies but the work
>>>>> looks to require a large manual effort to go through and cherry pick
>>>>> commits.  This is to ensure a cleaned up develop branch will merge
>>>>> cleanly to master.
>>>>> 
>>>>> I am starting to look into this again and found the following command
>>>>> to be useful:
>>>>> 
>>>>> git log --oneline --ancestry-path 652633..HEAD
>>>>> 
>>>>> which shows a series of commits that descend from 6.11.0 up until the
>>>>> HEAD of develop.  We can probably start from a later parent point to
>>>>> just before the date of the DMCA-related changes.
>>>>> 
>>>>> I am currently investigating branch cleanup work in a forked Csound
>>>>> repository under my user account on github.  I'll report anything I
>>>>> find here.
>>>>> 
>>>>> Steven
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Saludos,
>>>> Felipe Sateler
>> 
>> 
>> 
>> --

It appears we can revert the effects of git replace by deleting the entry
in .git/refs/replace/  , however until I get confirmation all is OK, I will not commit
anything to origin from my local.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 4 Sep 2018, at 09:30, Victor Lazzarini  wrote:
> 
> Hi Steven,
> 
> I started to look at this by reproducing your steps. I made a local branch (dev2) and tried the
> commands there. I also tried (blindly) to remove the other commit in the second 
> git replace command (git replace --edit 7894927615), with no change in commit numbers.
> 
> However, what worried me was that when I switched back to the develop branch, I had 
> 29k commits, which means that the edits I made were global (I did not expect that).
> 
> So now I am concerned that I will need to do a fresh checkout in order to carry on
> working otherwise in my next commit these experiments will be pushed to remote.
> 
> Anyway, it’s just a word of warning for anyone working on this
> 
> best regards
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>> 
>> I had some time to look at this today and it looks to me that these
>> two commits are the ones with issues:
>> 
>> 4a7ea2c7e6f91b4285ee393edd19d920a5ca5d03
>> 78949276150d6358728692e63d2d7b905d5eb927
>> 
>> I looked at the other two reported by Felipe but didn't see issues
>> when I used git log --ancestry-path to find ancestors.
>> 
>> For the first commit, I tried:
>> 
>> git log --oneline --ancestry-path 652633..cc84b96
>> git log --oneline --ancestry-path 652633..89ca172
>> 
>> and found the first had no shared commits, so:
>> 
>> BAD:  parent cc84b961d6b45c03354b0c66e989217e025b3db3
>> GOOD: parent 89ca1728077f0ec8152a766ad7c63500b29a166c
>> 
>> I modified using:
>> 
>> git replace --edit 4a7ea2c7e6
>> 
>> and erasing the line with cc84b961d
>> 
>> and I got:
>> 
>> $ git rev-list --count HEAD
>> 29931
>> 
>> Which seemed in the right direction.
>> 
>> To find the second commit, I used git bisect to go between the HEAD of
>> develop (bad) and 652633 (good). While bisecting, I used the 'git
>> rev-list --count HEAD' command to see if the number of commits was in
>> the 14k or 28k range and marked good/bad accordingly, ultimately
>> arriving at the second commit.
>> 
>> However, with the second commit, I tried something similar and found:
>> 
>> git log --oneline --ancestry-path 652633..e4ca0b12a
>> 
>> and found no shared commits.  But if I ran:
>> 
>> git replace --edit 7894927615
>> 
>> and removed the line with e4ca0b12a I still had 29K commits.
>> 
>> 
>> I'm not sure if my process is correct, but this seems like getting
>> closer.  If anyone else has time to look from here that'd be great as
>> this is tiring and my time at the moment is intermittent to look at
>> this.
>> 
>> On Tue, Aug 28, 2018 at 2:49 PM Felipe Sateler  wrote:
>>> 
>>> Also, this stackoverflow answer might be helpful:
>>> 
>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>> 
>>> On Tue, Aug 28, 2018 at 11:07 AM Steven Yi  wrote:
>>>> 
>>>> Thanks, that's valuable information.  I'll do some experimentation
>>>> today with rebasing and cherry picking.  May take some time to get
>>>> through this.
>>>> On Tue, Aug 28, 2018 at 9:20 AM Felipe Sateler  wrote:
>>>>> 
>>>>> I have a local repo with unclean history. This also has the benefit of having the old tags: the ones containing the vst code. I did the following:
>>>>> 
>>>>> gitk 6.11.0..develop
>>>>> 
>>>>> This gave me the history from the "old" 6.11.0 release to current develop. I could then pinpoint the first commit that merges both histories: 4a7ea2c7e6f91b4285ee393edd19d920a5ca5d03. There appears to be a second merge a bit later: either a3183704a2765f49b78124abb93704e8545814a9 or 54d13fee2e7450d3ef5066ffa2167f9073f66fdc , but I can't quite parse the commit graph from a quick look.
>>>>> 
>>>>> There don't appear to be any more merges from the parallel histories after 54d13fee2e7450d3ef5066ffa2167f9073f66fdc
>>>>> 
>>>>> Saludos
>>>>> 
>>>>> On Tue, Aug 28, 2018 at 12:54 AM Steven Yi  wrote:
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> As many know already, due to the DMCA takedown notice for VST-related
>>>>>> code that was in Csound, we had to move quickly to rewrite the git
>>>>>> history to remove any mention of VST-related code (24 hrs). After that
>>>>>> happened, and because we had rewritten git histories, merge commits
>>>>>> based on the older histories were done such that we now have
>>>>>> triplicate commits for a large part of the history for the develop
>>>>>> branch (master branch is clean).
>>>>>> 
>>>>>> We have spent a fair amount of time looking at strategies but the work
>>>>>> looks to require a large manual effort to go through and cherry pick
>>>>>> commits.  This is to ensure a cleaned up develop branch will merge
>>>>>> cleanly to master.
>>>>>> 
>>>>>> I am starting to look into this again and found the following command
>>>>>> to be useful:
>>>>>> 
>>>>>> git log --oneline --ancestry-path 652633..HEAD
>>>>>> 
>>>>>> which shows a series of commits that descend from 6.11.0 up until the
>>>>>> HEAD of develop.  We can probably start from a later parent point to
>>>>>> just before the date of the DMCA-related changes.
>>>>>> 
>>>>>> I am currently investigating branch cleanup work in a forked Csound
>>>>>> repository under my user account on github.  I'll report anything I
>>>>>> find here.
>>>>>> 
>>>>>> Steven
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Saludos,
>>>>> Felipe Sateler
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Saludos,
>>> Felipe Satele

Hi Steven

I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
were correct, so I suspected another commit. By checking the number of commits from that
last one you replaced onwards, I noticed that they were all 14k until 

2b6c5bffdd46e07dd36b44a04ce8cc19516520ef

which was a merge request commit. That seemed to have brought in the duplicate history.
I checked the parents

git log --oneline --ancestry-path 652633..00eb43efb
git log --oneline --ancestry-path 652633..1c7f7c7a0

and found that the first one had no shared commits and proceeded as you did,
removing it with git replace. Now I have

git rev-list --count HEAD
15049

So I think we found it. Two questions before we move to fix this:

1) It is a merge request. So we’ll loose the changes if we just replace it,
maybe we need to cherry pick?

2) Is git replace a permanent solution? It seems to be workable, but if the
refs get removed, we get the whole messed history back. 


best
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> 
> --oneline -

Hi Victor,

Thanks for looking into this! And sorry I should have mentioned the
.git/refs/replace thing; I ran into the same thing yesterday and
actually checked out a fresh copy of Csound before learning one could
just delete the entries in that folder.

I was proceeding from the StackOverflow link Felipe posted:

https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer

and in the first reply it says you can make the change permanent using either:

git filter-branch --tag-name-filter cat -- ..head

to only rewrite a range of commits, which seems appropriate.  I
suppose one could give it a try and check .git/refs/replace afterwards
to see if that hasn't been cleared up.

I'll give that a try now here locally to see what happens and report
back momentarily.  After that, my thought for the commit history that
was removed was to cherry-pick. One thing that's sort of interesting
to me is that, by removing commits from history, I would have expected
later commits to become something of a mess since things are diffs. I
suppose we're either lucky in that later commits don't touch the ones
that will get removed. Or perhaps the issues will arise on
filter-branch.

Will test now and reply in a moment.

Thanks!
steven




On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>
> Hi Steven
>
> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
> were correct, so I suspected another commit. By checking the number of commits from that
> last one you replaced onwards, I noticed that they were all 14k until
>
> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>
> which was a merge request commit. That seemed to have brought in the duplicate history.
> I checked the parents
>
> git log --oneline --ancestry-path 652633..00eb43efb
> git log --oneline --ancestry-path 652633..1c7f7c7a0
>
> and found that the first one had no shared commits and proceeded as you did,
> removing it with git replace. Now I have
>
> git rev-list --count HEAD
> 15049
>
> So I think we found it. Two questions before we move to fix this:
>
> 1) It is a merge request. So we’ll loose the changes if we just replace it,
> maybe we need to cherry pick?
>
> 2) Is git replace a permanent solution? It seems to be workable, but if the
> refs get removed, we get the whole messed history back.
>
>
> best
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
> > On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> >
> > --oneline --ancestry-path 652633..

Hi Steven,

sounds like a good plan. Finding the commit in the end was not too complicated as
you had already figured out a good method.

best
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 4 Sep 2018, at 11:57, Steven Yi  wrote:
> 
> Hi Victor,
> 
> Thanks for looking into this! And sorry I should have mentioned the
> .git/refs/replace thing; I ran into the same thing yesterday and
> actually checked out a fresh copy of Csound before learning one could
> just delete the entries in that folder.
> 
> I was proceeding from the StackOverflow link Felipe posted:
> 
> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
> 
> and in the first reply it says you can make the change permanent using either:
> 
> git filter-branch --tag-name-filter cat -- ..head
> 
> to only rewrite a range of commits, which seems appropriate.  I
> suppose one could give it a try and check .git/refs/replace afterwards
> to see if that hasn't been cleared up.
> 
> I'll give that a try now here locally to see what happens and report
> back momentarily.  After that, my thought for the commit history that
> was removed was to cherry-pick. One thing that's sort of interesting
> to me is that, by removing commits from history, I would have expected
> later commits to become something of a mess since things are diffs. I
> suppose we're either lucky in that later commits don't touch the ones
> that will get removed. Or perhaps the issues will arise on
> filter-branch.
> 
> Will test now and reply in a moment.
> 
> Thanks!
> steven
> 
> 
> 
> 
> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>> 
>> Hi Steven
>> 
>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>> were correct, so I suspected another commit. By checking the number of commits from that
>> last one you replaced onwards, I noticed that they were all 14k until
>> 
>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>> 
>> which was a merge request commit. That seemed to have brought in the duplicate history.
>> I checked the parents
>> 
>> git log --oneline --ancestry-path 652633..00eb43efb
>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>> 
>> and found that the first one had no shared commits and proceeded as you did,
>> removing it with git replace. Now I have
>> 
>> git rev-list --count HEAD
>> 15049
>> 
>> So I think we found it. Two questions before we move to fix this:
>> 
>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>> maybe we need to cherry pick?
>> 
>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>> refs get removed, we get the whole messed history back.
>> 
>> 
>> best
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>> 
>>> --oneli

I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
but still had 29931 commits afterwards. Victor: did you modify any
other commits too?  I'm not sure what I might be doing differently
here locally.

I see that that commit was a merge from a pull request related to
fixes for WebAudio Csound. It looks like since the VST cleaning, there
were a few other pull requests.

Side note, I saw this on the github page for removing sensitive data
from a git repository
(https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
I think we used this when we did the VST-related change):

"Tell your collaborators to rebase, not merge, any branches they
created off of your old (tainted) repository history. One merge commit
could reintroduce some or all of the tainted history that you just
went to the trouble of purging."


On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>
> Hi Victor,
>
> Thanks for looking into this! And sorry I should have mentioned the
> .git/refs/replace thing; I ran into the same thing yesterday and
> actually checked out a fresh copy of Csound before learning one could
> just delete the entries in that folder.
>
> I was proceeding from the StackOverflow link Felipe posted:
>
> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>
> and in the first reply it says you can make the change permanent using either:
>
> git filter-branch --tag-name-filter cat -- ..head
>
> to only rewrite a range of commits, which seems appropriate.  I
> suppose one could give it a try and check .git/refs/replace afterwards
> to see if that hasn't been cleared up.
>
> I'll give that a try now here locally to see what happens and report
> back momentarily.  After that, my thought for the commit history that
> was removed was to cherry-pick. One thing that's sort of interesting
> to me is that, by removing commits from history, I would have expected
> later commits to become something of a mess since things are diffs. I
> suppose we're either lucky in that later commits don't touch the ones
> that will get removed. Or perhaps the issues will arise on
> filter-branch.
>
> Will test now and reply in a moment.
>
> Thanks!
> steven
>
>
>
>
> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
> >
> > Hi Steven
> >
> > I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
> > were correct, so I suspected another commit. By checking the number of commits from that
> > last one you replaced onwards, I noticed that they were all 14k until
> >
> > 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >
> > which was a merge request commit. That seemed to have brought in the duplicate history.
> > I checked the parents
> >
> > git log --oneline --ancestry-path 652633..00eb43efb
> > git log --oneline --ancestry-path 652633..1c7f7c7a0
> >
> > and found that the first one had no shared commits and proceeded as you did,
> > removing it with git replace. Now I have
> >
> > git rev-list --count HEAD
> > 15049
> >
> > So I think we found it. Two questions before we move to fix this:
> >
> > 1) It is a merge request. So we’ll loose the changes if we just replace it,
> > maybe we need to cherry pick?
> >
> > 2) Is git replace a permanent solution? It seems to be workable, but if the
> > refs get removed, we get the whole messed history back.
> >
> >
> > best
> > ========================
> > Prof. Victor Lazzarini
> > Dean of Arts, Celtic Studies, and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> > > On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> > >
> > > --oneline --ancestry-path 652633..

I did three modifications:

1) git replace --edit 4a7ea2c7e6

removing cc84b961d

2) git replace --edit 7894927615

removing e4ca0b12a

3) git replace —edit 2b6c5bffdd46e07

removing 00eb43efb

and ended up with 15k commits in HEAD.


And yes I saw that paragraph at the time and it horrified me.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
> 
> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> but still had 29931 commits afterwards. Victor: did you modify any
> other commits too?  I'm not sure what I might be doing differently
> here locally.
> 
> I see that that commit was a merge from a pull request related to
> fixes for WebAudio Csound. It looks like since the VST cleaning, there
> were a few other pull requests.
> 
> Side note, I saw this on the github page for removing sensitive data
> from a git repository
> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
> I think we used this when we did the VST-related change):
> 
> "Tell your collaborators to rebase, not merge, any branches they
> created off of your old (tainted) repository history. One merge commit
> could reintroduce some or all of the tainted history that you just
> went to the trouble of purging."
> 
> 
> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>> 
>> Hi Victor,
>> 
>> Thanks for looking into this! And sorry I should have mentioned the
>> .git/refs/replace thing; I ran into the same thing yesterday and
>> actually checked out a fresh copy of Csound before learning one could
>> just delete the entries in that folder.
>> 
>> I was proceeding from the StackOverflow link Felipe posted:
>> 
>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>> 
>> and in the first reply it says you can make the change permanent using either:
>> 
>> git filter-branch --tag-name-filter cat -- ..head
>> 
>> to only rewrite a range of commits, which seems appropriate.  I
>> suppose one could give it a try and check .git/refs/replace afterwards
>> to see if that hasn't been cleared up.
>> 
>> I'll give that a try now here locally to see what happens and report
>> back momentarily.  After that, my thought for the commit history that
>> was removed was to cherry-pick. One thing that's sort of interesting
>> to me is that, by removing commits from history, I would have expected
>> later commits to become something of a mess since things are diffs. I
>> suppose we're either lucky in that later commits don't touch the ones
>> that will get removed. Or perhaps the issues will arise on
>> filter-branch.
>> 
>> Will test now and reply in a moment.
>> 
>> Thanks!
>> steven
>> 
>> 
>> 
>> 
>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>> 
>>> Hi Steven
>>> 
>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>> were correct, so I suspected another commit. By checking the number of commits from that
>>> last one you replaced onwards, I noticed that they were all 14k until
>>> 
>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>> 
>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>> I checked the parents
>>> 
>>> git log --oneline --ancestry-path 652633..00eb43efb
>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>> 
>>> and found that the first one had no shared commits and proceeded as you did,
>>> removing it with git replace. Now I have
>>> 
>>> git rev-list --count HEAD
>>> 15049
>>> 
>>> So I think we found it. Two questions before we move to fix this:
>>> 
>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>> maybe we need to cherry pick?
>>> 
>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>> refs get removed, we get the whole messed history back.
>>> 
>>> 
>>> best
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>> 
>>>> --oneline --ancestry-p

Ah thanks, the third one there did it for me here. I'm trying out the
filter-branch now, but I'm wondering if there's a better way.  My
thought is:

1. If we remove the parent, we lose the commits, somewhat going from:

...a -> b -> c -> merge commit ->
...x-> q -> z ->   ---^

to just:

...a -> b -> c -> merge commit ->

If we do that, maybe q and z are good commits we want, but x and
everything before is not. Here we were then talking about cherry
picking.

2. Maybe instead of editing the merge commit, we modify the earliest
interesting commit.  So for the above, maybe we edit q, change its
parent to c, then hopefully all is right, something like:

...a -> b -> c ------->  merge commit ->
                  \--> q -> z ->   ---^


Regarding the first path, I just tried running the filter branch with:

$ git filter-branch --tag-name-filter cat -- 652633..head
Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
seconds passed, remaining 0 predicted)
Ref 'refs/heads/develop' was rewritten

and got the above. I could then delete the entries in
.git/refs/replace and still have 15K entries.


I think we should try #2 next, as in my head it's sort of what we're
wanting in the end and seems more correct than trying to cherry-pick.
(Could use the same replace --edit command I think.) I've got a fair
amount of other work to do now, but will try to take a look later in
the day if you haven't gotten to it first.

On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>
> I did three modifications:
>
> 1) git replace --edit 4a7ea2c7e6
>
> removing cc84b961d
>
> 2) git replace --edit 7894927615
>
> removing e4ca0b12a
>
> 3) git replace —edit 2b6c5bffdd46e07
>
> removing 00eb43efb
>
> and ended up with 15k commits in HEAD.
>
>
> And yes I saw that paragraph at the time and it horrified me.
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
> > On 4 Sep 2018, at 12:12, Steven Yi  wrote:
> >
> > I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> > but still had 29931 commits afterwards. Victor: did you modify any
> > other commits too?  I'm not sure what I might be doing differently
> > here locally.
> >
> > I see that that commit was a merge from a pull request related to
> > fixes for WebAudio Csound. It looks like since the VST cleaning, there
> > were a few other pull requests.
> >
> > Side note, I saw this on the github page for removing sensitive data
> > from a git repository
> > (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
> > I think we used this when we did the VST-related change):
> >
> > "Tell your collaborators to rebase, not merge, any branches they
> > created off of your old (tainted) repository history. One merge commit
> > could reintroduce some or all of the tainted history that you just
> > went to the trouble of purging."
> >
> >
> > On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
> >>
> >> Hi Victor,
> >>
> >> Thanks for looking into this! And sorry I should have mentioned the
> >> .git/refs/replace thing; I ran into the same thing yesterday and
> >> actually checked out a fresh copy of Csound before learning one could
> >> just delete the entries in that folder.
> >>
> >> I was proceeding from the StackOverflow link Felipe posted:
> >>
> >> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
> >>
> >> and in the first reply it says you can make the change permanent using either:
> >>
> >> git filter-branch --tag-name-filter cat -- ..head
> >>
> >> to only rewrite a range of commits, which seems appropriate.  I
> >> suppose one could give it a try and check .git/refs/replace afterwards
> >> to see if that hasn't been cleared up.
> >>
> >> I'll give that a try now here locally to see what happens and report
> >> back momentarily.  After that, my thought for the commit history that
> >> was removed was to cherry-pick. One thing that's sort of interesting
> >> to me is that, by removing commits from history, I would have expected
> >> later commits to become something of a mess since things are diffs. I
> >> suppose we're either lucky in that later commits don't touch the ones
> >> that will get removed. Or perhaps the issues will arise on
> >> filter-branch.
> >>
> >> Will test now and reply in a moment.
> >>
> >> Thanks!
> >> steven
> >>
> >>
> >>
> >>
> >> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
> >>>
> >>> Hi Steven
> >>>
> >>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
> >>> were correct, so I suspected another commit. By checking the number of commits from that
> >>> last one you replaced onwards, I noticed that they were all 14k until
> >>>
> >>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>
> >>> which was a merge request commit. That seemed to have brought in the duplicate history.
> >>> I checked the parents
> >>>
> >>> git log --oneline --ancestry-path 652633..00eb43efb
> >>> git log --oneline --ancestry-path 652633..1c7f7c7a0
> >>>
> >>> and found that the first one had no shared commits and proceeded as you did,
> >>> removing it with git replace. Now I have
> >>>
> >>> git rev-list --count HEAD
> >>> 15049
> >>>
> >>> So I think we found it. Two questions before we move to fix this:
> >>>
> >>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
> >>> maybe we need to cherry pick?
> >>>
> >>> 2) Is git replace a permanent solution? It seems to be workable, but if the
> >>> refs get removed, we get the whole messed history back.
> >>>
> >>>
> >>> best
> >>> ========================
> >>> Prof. Victor Lazzarini
> >>> Dean of Arts, Celtic Studies, and Philosophy,
> >>> Maynooth University,
> >>> Maynooth, Co Kildare, Ireland
> >>> Tel: 00 353 7086936
> >>> Fax: 00 353 1 7086952
> >>>
> >>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> >>>>
> >>>> --oneline --ancestry-path 652633..
> >>>

Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
cherry picking involved. For the third one, we can attempt 2) as there is a couple of
commits we want to keep.

In any case,  if 1) works and we can always cherry pick.

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
> 
> Ah thanks, the third one there did it for me here. I'm trying out the
> filter-branch now, but I'm wondering if there's a better way.  My
> thought is:
> 
> 1. If we remove the parent, we lose the commits, somewhat going from:
> 
> ...a -> b -> c -> merge commit ->
> ...x-> q -> z ->   ---^
> 
> to just:
> 
> ...a -> b -> c -> merge commit ->
> 
> If we do that, maybe q and z are good commits we want, but x and
> everything before is not. Here we were then talking about cherry
> picking.
> 
> 2. Maybe instead of editing the merge commit, we modify the earliest
> interesting commit.  So for the above, maybe we edit q, change its
> parent to c, then hopefully all is right, something like:
> 
> ...a -> b -> c ------->  merge commit ->
>                  \--> q -> z ->   ---^
> 
> 
> Regarding the first path, I just tried running the filter branch with:
> 
> $ git filter-branch --tag-name-filter cat -- 652633..head
> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
> seconds passed, remaining 0 predicted)
> Ref 'refs/heads/develop' was rewritten
> 
> and got the above. I could then delete the entries in
> .git/refs/replace and still have 15K entries.
> 
> 
> I think we should try #2 next, as in my head it's sort of what we're
> wanting in the end and seems more correct than trying to cherry-pick.
> (Could use the same replace --edit command I think.) I've got a fair
> amount of other work to do now, but will try to take a look later in
> the day if you haven't gotten to it first.
> 
> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>> 
>> I did three modifications:
>> 
>> 1) git replace --edit 4a7ea2c7e6
>> 
>> removing cc84b961d
>> 
>> 2) git replace --edit 7894927615
>> 
>> removing e4ca0b12a
>> 
>> 3) git replace —edit 2b6c5bffdd46e07
>> 
>> removing 00eb43efb
>> 
>> and ended up with 15k commits in HEAD.
>> 
>> 
>> And yes I saw that paragraph at the time and it horrified me.
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>> 
>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>> but still had 29931 commits afterwards. Victor: did you modify any
>>> other commits too?  I'm not sure what I might be doing differently
>>> here locally.
>>> 
>>> I see that that commit was a merge from a pull request related to
>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>> were a few other pull requests.
>>> 
>>> Side note, I saw this on the github page for removing sensitive data
>>> from a git repository
>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>> I think we used this when we did the VST-related change):
>>> 
>>> "Tell your collaborators to rebase, not merge, any branches they
>>> created off of your old (tainted) repository history. One merge commit
>>> could reintroduce some or all of the tainted history that you just
>>> went to the trouble of purging."
>>> 
>>> 
>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>> 
>>>> Hi Victor,
>>>> 
>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>> actually checked out a fresh copy of Csound before learning one could
>>>> just delete the entries in that folder.
>>>> 
>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>> 
>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>> 
>>>> and in the first reply it says you can make the change permanent using either:
>>>> 
>>>> git filter-branch --tag-name-filter cat -- ..head
>>>> 
>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>> to see if that hasn't been cleared up.
>>>> 
>>>> I'll give that a try now here locally to see what happens and report
>>>> back momentarily.  After that, my thought for the commit history that
>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>> to me is that, by removing commits from history, I would have expected
>>>> later commits to become something of a mess since things are diffs. I
>>>> suppose we're either lucky in that later commits don't touch the ones
>>>> that will get removed. Or perhaps the issues will arise on
>>>> filter-branch.
>>>> 
>>>> Will test now and reply in a moment.
>>>> 
>>>> Thanks!
>>>> steven
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>> 
>>>>> Hi Steven
>>>>> 
>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>> 
>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>> 
>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>> I checked the parents
>>>>> 
>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>> 
>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>> removing it with git replace. Now I have
>>>>> 
>>>>> git rev-list --count HEAD
>>>>> 15049
>>>>> 
>>>>> So I think we found it. Two questions before we move to fix this:
>>>>> 
>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>> maybe we need to cherry pick?
>>>>> 
>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>> refs get removed, we get the whole messed history back.
>>>>> 
>>>>> 
>>>>> best
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952
>>>>> 
>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>> 
>>>>>> --

Btw, let me know if you want help with this.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
> 
> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
> commits we want to keep.
> 
> In any case,  if 1) works and we can always cherry pick.
> 
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>> 
>> Ah thanks, the third one there did it for me here. I'm trying out the
>> filter-branch now, but I'm wondering if there's a better way.  My
>> thought is:
>> 
>> 1. If we remove the parent, we lose the commits, somewhat going from:
>> 
>> ...a -> b -> c -> merge commit ->
>> ...x-> q -> z ->   ---^
>> 
>> to just:
>> 
>> ...a -> b -> c -> merge commit ->
>> 
>> If we do that, maybe q and z are good commits we want, but x and
>> everything before is not. Here we were then talking about cherry
>> picking.
>> 
>> 2. Maybe instead of editing the merge commit, we modify the earliest
>> interesting commit.  So for the above, maybe we edit q, change its
>> parent to c, then hopefully all is right, something like:
>> 
>> ...a -> b -> c ------->  merge commit ->
>>                 \--> q -> z ->   ---^
>> 
>> 
>> Regarding the first path, I just tried running the filter branch with:
>> 
>> $ git filter-branch --tag-name-filter cat -- 652633..head
>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>> seconds passed, remaining 0 predicted)
>> Ref 'refs/heads/develop' was rewritten
>> 
>> and got the above. I could then delete the entries in
>> .git/refs/replace and still have 15K entries.
>> 
>> 
>> I think we should try #2 next, as in my head it's sort of what we're
>> wanting in the end and seems more correct than trying to cherry-pick.
>> (Could use the same replace --edit command I think.) I've got a fair
>> amount of other work to do now, but will try to take a look later in
>> the day if you haven't gotten to it first.
>> 
>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>> 
>>> I did three modifications:
>>> 
>>> 1) git replace --edit 4a7ea2c7e6
>>> 
>>> removing cc84b961d
>>> 
>>> 2) git replace --edit 7894927615
>>> 
>>> removing e4ca0b12a
>>> 
>>> 3) git replace —edit 2b6c5bffdd46e07
>>> 
>>> removing 00eb43efb
>>> 
>>> and ended up with 15k commits in HEAD.
>>> 
>>> 
>>> And yes I saw that paragraph at the time and it horrified me.
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>> 
>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>> other commits too?  I'm not sure what I might be doing differently
>>>> here locally.
>>>> 
>>>> I see that that commit was a merge from a pull request related to
>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>> were a few other pull requests.
>>>> 
>>>> Side note, I saw this on the github page for removing sensitive data
>>>> from a git repository
>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>> I think we used this when we did the VST-related change):
>>>> 
>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>> created off of your old (tainted) repository history. One merge commit
>>>> could reintroduce some or all of the tainted history that you just
>>>> went to the trouble of purging."
>>>> 
>>>> 
>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>> 
>>>>> Hi Victor,
>>>>> 
>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>> just delete the entries in that folder.
>>>>> 
>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>> 
>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>> 
>>>>> and in the first reply it says you can make the change permanent using either:
>>>>> 
>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>> 
>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>> to see if that hasn't been cleared up.
>>>>> 
>>>>> I'll give that a try now here locally to see what happens and report
>>>>> back momentarily.  After that, my thought for the commit history that
>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>> to me is that, by removing commits from history, I would have expected
>>>>> later commits to become something of a mess since things are diffs. I
>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>> that will get removed. Or perhaps the issues will arise on
>>>>> filter-branch.
>>>>> 
>>>>> Will test now and reply in a moment.
>>>>> 
>>>>> Thanks!
>>>>> steven
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Hi Steven
>>>>>> 
>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>> 
>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>> 
>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>> I checked the parents
>>>>>> 
>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>> 
>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>> removing it with git replace. Now I have
>>>>>> 
>>>>>> git rev-list --count HEAD
>>>>>> 15049
>>>>>> 
>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>> 
>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>> maybe we need to cherry pick?
>>>>>> 
>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>> refs get removed, we get the whole messed history back.
>>>>>> 
>>>>>> 
>>>>>> best
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>> 
>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>> 
>>>>>>> --oneline --ancestry-path 652633..
>>>>>> 

Yes, please do give it a go if you have the time. (I'm a bit
intermittent to get to most anything outside of work at the moment.)
On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>
> Btw, let me know if you want help with this.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
> > On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
> >
> > Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
> > cherry picking involved. For the third one, we can attempt 2) as there is a couple of
> > commits we want to keep.
> >
> > In any case,  if 1) works and we can always cherry pick.
> >
> > ========================
> > Prof. Victor Lazzarini
> > Dean of Arts, Celtic Studies, and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> >> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
> >>
> >> Ah thanks, the third one there did it for me here. I'm trying out the
> >> filter-branch now, but I'm wondering if there's a better way.  My
> >> thought is:
> >>
> >> 1. If we remove the parent, we lose the commits, somewhat going from:
> >>
> >> ...a -> b -> c -> merge commit ->
> >> ...x-> q -> z ->   ---^
> >>
> >> to just:
> >>
> >> ...a -> b -> c -> merge commit ->
> >>
> >> If we do that, maybe q and z are good commits we want, but x and
> >> everything before is not. Here we were then talking about cherry
> >> picking.
> >>
> >> 2. Maybe instead of editing the merge commit, we modify the earliest
> >> interesting commit.  So for the above, maybe we edit q, change its
> >> parent to c, then hopefully all is right, something like:
> >>
> >> ...a -> b -> c ------->  merge commit ->
> >>                 \--> q -> z ->   ---^
> >>
> >>
> >> Regarding the first path, I just tried running the filter branch with:
> >>
> >> $ git filter-branch --tag-name-filter cat -- 652633..head
> >> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
> >> seconds passed, remaining 0 predicted)
> >> Ref 'refs/heads/develop' was rewritten
> >>
> >> and got the above. I could then delete the entries in
> >> .git/refs/replace and still have 15K entries.
> >>
> >>
> >> I think we should try #2 next, as in my head it's sort of what we're
> >> wanting in the end and seems more correct than trying to cherry-pick.
> >> (Could use the same replace --edit command I think.) I've got a fair
> >> amount of other work to do now, but will try to take a look later in
> >> the day if you haven't gotten to it first.
> >>
> >> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
> >>>
> >>> I did three modifications:
> >>>
> >>> 1) git replace --edit 4a7ea2c7e6
> >>>
> >>> removing cc84b961d
> >>>
> >>> 2) git replace --edit 7894927615
> >>>
> >>> removing e4ca0b12a
> >>>
> >>> 3) git replace —edit 2b6c5bffdd46e07
> >>>
> >>> removing 00eb43efb
> >>>
> >>> and ended up with 15k commits in HEAD.
> >>>
> >>>
> >>> And yes I saw that paragraph at the time and it horrified me.
> >>>
> >>> ========================
> >>> Prof. Victor Lazzarini
> >>> Dean of Arts, Celtic Studies, and Philosophy,
> >>> Maynooth University,
> >>> Maynooth, Co Kildare, Ireland
> >>> Tel: 00 353 7086936
> >>> Fax: 00 353 1 7086952
> >>>
> >>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
> >>>>
> >>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>> but still had 29931 commits afterwards. Victor: did you modify any
> >>>> other commits too?  I'm not sure what I might be doing differently
> >>>> here locally.
> >>>>
> >>>> I see that that commit was a merge from a pull request related to
> >>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
> >>>> were a few other pull requests.
> >>>>
> >>>> Side note, I saw this on the github page for removing sensitive data
> >>>> from a git repository
> >>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
> >>>> I think we used this when we did the VST-related change):
> >>>>
> >>>> "Tell your collaborators to rebase, not merge, any branches they
> >>>> created off of your old (tainted) repository history. One merge commit
> >>>> could reintroduce some or all of the tainted history that you just
> >>>> went to the trouble of purging."
> >>>>
> >>>>
> >>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
> >>>>>
> >>>>> Hi Victor,
> >>>>>
> >>>>> Thanks for looking into this! And sorry I should have mentioned the
> >>>>> .git/refs/replace thing; I ran into the same thing yesterday and
> >>>>> actually checked out a fresh copy of Csound before learning one could
> >>>>> just delete the entries in that folder.
> >>>>>
> >>>>> I was proceeding from the StackOverflow link Felipe posted:
> >>>>>
> >>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
> >>>>>
> >>>>> and in the first reply it says you can make the change permanent using either:
> >>>>>
> >>>>> git filter-branch --tag-name-filter cat -- ..head
> >>>>>
> >>>>> to only rewrite a range of commits, which seems appropriate.  I
> >>>>> suppose one could give it a try and check .git/refs/replace afterwards
> >>>>> to see if that hasn't been cleared up.
> >>>>>
> >>>>> I'll give that a try now here locally to see what happens and report
> >>>>> back momentarily.  After that, my thought for the commit history that
> >>>>> was removed was to cherry-pick. One thing that's sort of interesting
> >>>>> to me is that, by removing commits from history, I would have expected
> >>>>> later commits to become something of a mess since things are diffs. I
> >>>>> suppose we're either lucky in that later commits don't touch the ones
> >>>>> that will get removed. Or perhaps the issues will arise on
> >>>>> filter-branch.
> >>>>>
> >>>>> Will test now and reply in a moment.
> >>>>>
> >>>>> Thanks!
> >>>>> steven
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
> >>>>>>
> >>>>>> Hi Steven
> >>>>>>
> >>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
> >>>>>> were correct, so I suspected another commit. By checking the number of commits from that
> >>>>>> last one you replaced onwards, I noticed that they were all 14k until
> >>>>>>
> >>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>>>>
> >>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
> >>>>>> I checked the parents
> >>>>>>
> >>>>>> git log --oneline --ancestry-path 652633..00eb43efb
> >>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
> >>>>>>
> >>>>>> and found that the first one had no shared commits and proceeded as you did,
> >>>>>> removing it with git replace. Now I have
> >>>>>>
> >>>>>> git rev-list --count HEAD
> >>>>>> 15049
> >>>>>>
> >>>>>> So I think we found it. Two questions before we move to fix this:
> >>>>>>
> >>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
> >>>>>> maybe we need to cherry pick?
> >>>>>>
> >>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
> >>>>>> refs get removed, we get the whole messed history back.
> >>>>>>
> >>>>>>
> >>>>>> best
> >>>>>> ========================
> >>>>>> Prof. Victor Lazzarini
> >>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>> Maynooth University,
> >>>>>> Maynooth, Co Kildare, Ireland
> >>>>>> Tel: 00 353 7086936
> >>>>>> Fax: 00 353 1 7086952
> >>>>>>
> >>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> >>>>>>>
> >>>>>>> --oneline --ancestry-path 652633..
> >>>>>>
> >>>
> >

Ok, pursuing your second idea, I’ve got some better results. Here’s what I did

1) For the first two commits, I just replaced the merge as before

$ git replace --edit 4a7ea2c7e6
removing cc84b961d
$ git replace --edit 7894927615
removing e4ca0b12a

2) For the third one, I examined the tree starting from 2b6c5bffdd46e07 
and found two commits back in the history that there was a duplicate
merge. 

The child of one of this duplicates is (two down from 2b6c5bffd)
4e4721c9f85329c490b3114d3b8c0816ea90e35c

the parent, one of the duplicate merges, is

394c43edd0dd68f992647f51b00f78c33564987a

and the correct merge in the history was

8372f32b8aa6d2d90da8900ddadeea8f157df1a5

So I edited 
$ git replace --edit 4e4721c9f85329
and replaced the first (39…) by the second (83...)

Now I have 15051 commits. I think we can apply 
filter-branch to this and it will fix the problem. You can
re-trace my steps above and verify it.

I have pushed a dev2 branch to which I applied
the filter so you can have a look at.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
> 
> Yes, please do give it a go if you have the time. (I'm a bit
> intermittent to get to most anything outside of work at the moment.)
> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>> 
>> Btw, let me know if you want help with this.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>>> 
>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>>> commits we want to keep.
>>> 
>>> In any case,  if 1) works and we can always cherry pick.
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>>>> 
>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>>>> filter-branch now, but I'm wondering if there's a better way.  My
>>>> thought is:
>>>> 
>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>>>> 
>>>> ...a -> b -> c -> merge commit ->
>>>> ...x-> q -> z ->   ---^
>>>> 
>>>> to just:
>>>> 
>>>> ...a -> b -> c -> merge commit ->
>>>> 
>>>> If we do that, maybe q and z are good commits we want, but x and
>>>> everything before is not. Here we were then talking about cherry
>>>> picking.
>>>> 
>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>>>> interesting commit.  So for the above, maybe we edit q, change its
>>>> parent to c, then hopefully all is right, something like:
>>>> 
>>>> ...a -> b -> c ------->  merge commit ->
>>>>                \--> q -> z ->   ---^
>>>> 
>>>> 
>>>> Regarding the first path, I just tried running the filter branch with:
>>>> 
>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>>>> seconds passed, remaining 0 predicted)
>>>> Ref 'refs/heads/develop' was rewritten
>>>> 
>>>> and got the above. I could then delete the entries in
>>>> .git/refs/replace and still have 15K entries.
>>>> 
>>>> 
>>>> I think we should try #2 next, as in my head it's sort of what we're
>>>> wanting in the end and seems more correct than trying to cherry-pick.
>>>> (Could use the same replace --edit command I think.) I've got a fair
>>>> amount of other work to do now, but will try to take a look later in
>>>> the day if you haven't gotten to it first.
>>>> 
>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>>>> 
>>>>> I did three modifications:
>>>>> 
>>>>> 1) git replace --edit 4a7ea2c7e6
>>>>> 
>>>>> removing cc84b961d
>>>>> 
>>>>> 2) git replace --edit 7894927615
>>>>> 
>>>>> removing e4ca0b12a
>>>>> 
>>>>> 3) git replace —edit 2b6c5bffdd46e07
>>>>> 
>>>>> removing 00eb43efb
>>>>> 
>>>>> and ended up with 15k commits in HEAD.
>>>>> 
>>>>> 
>>>>> And yes I saw that paragraph at the time and it horrified me.
>>>>> 
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952
>>>>> 
>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>>>> 
>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>>>> other commits too?  I'm not sure what I might be doing differently
>>>>>> here locally.
>>>>>> 
>>>>>> I see that that commit was a merge from a pull request related to
>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>>>> were a few other pull requests.
>>>>>> 
>>>>>> Side note, I saw this on the github page for removing sensitive data
>>>>>> from a git repository
>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>>>> I think we used this when we did the VST-related change):
>>>>>> 
>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>>>> created off of your old (tainted) repository history. One merge commit
>>>>>> could reintroduce some or all of the tainted history that you just
>>>>>> went to the trouble of purging."
>>>>>> 
>>>>>> 
>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>>>> 
>>>>>>> Hi Victor,
>>>>>>> 
>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>>>> just delete the entries in that folder.
>>>>>>> 
>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>>>> 
>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>>>> 
>>>>>>> and in the first reply it says you can make the change permanent using either:
>>>>>>> 
>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>>>> 
>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>>>> to see if that hasn't been cleared up.
>>>>>>> 
>>>>>>> I'll give that a try now here locally to see what happens and report
>>>>>>> back momentarily.  After that, my thought for the commit history that
>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>>>> to me is that, by removing commits from history, I would have expected
>>>>>>> later commits to become something of a mess since things are diffs. I
>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>>>> that will get removed. Or perhaps the issues will arise on
>>>>>>> filter-branch.
>>>>>>> 
>>>>>>> Will test now and reply in a moment.
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> Hi Steven
>>>>>>>> 
>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>>>> 
>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>> 
>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>>>> I checked the parents
>>>>>>>> 
>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>>>> 
>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>>>> removing it with git replace. Now I have
>>>>>>>> 
>>>>>>>> git rev-list --count HEAD
>>>>>>>> 15049
>>>>>>>> 
>>>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>>>> 
>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>>>> maybe we need to cherry pick?
>>>>>>>> 
>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>>>> refs get removed, we get the whole messed history back.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> best
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>> 
>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>>>> 
>>>>>>>>> --oneline --ancestry-path 652633

Ops, only realised the dev2 branch was already there. I will make it develop2
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
> 
> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
> 
> 1) For the first two commits, I just replaced the merge as before
> 
> $ git replace --edit 4a7ea2c7e6
> removing cc84b961d
> $ git replace --edit 7894927615
> removing e4ca0b12a
> 
> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07 
> and found two commits back in the history that there was a duplicate
> merge. 
> 
> The child of one of this duplicates is (two down from 2b6c5bffd)
> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
> 
> the parent, one of the duplicate merges, is
> 
> 394c43edd0dd68f992647f51b00f78c33564987a
> 
> and the correct merge in the history was
> 
> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
> 
> So I edited 
> $ git replace --edit 4e4721c9f85329
> and replaced the first (39…) by the second (83...)
> 
> Now I have 15051 commits. I think we can apply 
> filter-branch to this and it will fix the problem. You can
> re-trace my steps above and verify it.
> 
> I have pushed a dev2 branch to which I applied
> the filter so you can have a look at.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
>> 
>> Yes, please do give it a go if you have the time. (I'm a bit
>> intermittent to get to most anything outside of work at the moment.)
>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>>> 
>>> Btw, let me know if you want help with this.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>>>> 
>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>>>> commits we want to keep.
>>>> 
>>>> In any case,  if 1) works and we can always cherry pick.
>>>> 
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>> 
>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>>>>> 
>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>>>>> filter-branch now, but I'm wondering if there's a better way.  My
>>>>> thought is:
>>>>> 
>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>>>>> 
>>>>> ...a -> b -> c -> merge commit ->
>>>>> ...x-> q -> z ->   ---^
>>>>> 
>>>>> to just:
>>>>> 
>>>>> ...a -> b -> c -> merge commit ->
>>>>> 
>>>>> If we do that, maybe q and z are good commits we want, but x and
>>>>> everything before is not. Here we were then talking about cherry
>>>>> picking.
>>>>> 
>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>>>>> interesting commit.  So for the above, maybe we edit q, change its
>>>>> parent to c, then hopefully all is right, something like:
>>>>> 
>>>>> ...a -> b -> c ------->  merge commit ->
>>>>>               \--> q -> z ->   ---^
>>>>> 
>>>>> 
>>>>> Regarding the first path, I just tried running the filter branch with:
>>>>> 
>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>>>>> seconds passed, remaining 0 predicted)
>>>>> Ref 'refs/heads/develop' was rewritten
>>>>> 
>>>>> and got the above. I could then delete the entries in
>>>>> .git/refs/replace and still have 15K entries.
>>>>> 
>>>>> 
>>>>> I think we should try #2 next, as in my head it's sort of what we're
>>>>> wanting in the end and seems more correct than trying to cherry-pick.
>>>>> (Could use the same replace --edit command I think.) I've got a fair
>>>>> amount of other work to do now, but will try to take a look later in
>>>>> the day if you haven't gotten to it first.
>>>>> 
>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>>>>> 
>>>>>> I did three modifications:
>>>>>> 
>>>>>> 1) git replace --edit 4a7ea2c7e6
>>>>>> 
>>>>>> removing cc84b961d
>>>>>> 
>>>>>> 2) git replace --edit 7894927615
>>>>>> 
>>>>>> removing e4ca0b12a
>>>>>> 
>>>>>> 3) git replace —edit 2b6c5bffdd46e07
>>>>>> 
>>>>>> removing 00eb43efb
>>>>>> 
>>>>>> and ended up with 15k commits in HEAD.
>>>>>> 
>>>>>> 
>>>>>> And yes I saw that paragraph at the time and it horrified me.
>>>>>> 
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>> 
>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>>>>> 
>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>>>>> other commits too?  I'm not sure what I might be doing differently
>>>>>>> here locally.
>>>>>>> 
>>>>>>> I see that that commit was a merge from a pull request related to
>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>>>>> were a few other pull requests.
>>>>>>> 
>>>>>>> Side note, I saw this on the github page for removing sensitive data
>>>>>>> from a git repository
>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>>>>> I think we used this when we did the VST-related change):
>>>>>>> 
>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>>>>> created off of your old (tainted) repository history. One merge commit
>>>>>>> could reintroduce some or all of the tainted history that you just
>>>>>>> went to the trouble of purging."
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> Hi Victor,
>>>>>>>> 
>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>>>>> just delete the entries in that folder.
>>>>>>>> 
>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>>>>> 
>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>>>>> 
>>>>>>>> and in the first reply it says you can make the change permanent using either:
>>>>>>>> 
>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>>>>> 
>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>>>>> to see if that hasn't been cleared up.
>>>>>>>> 
>>>>>>>> I'll give that a try now here locally to see what happens and report
>>>>>>>> back momentarily.  After that, my thought for the commit history that
>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>>>>> to me is that, by removing commits from history, I would have expected
>>>>>>>> later commits to become something of a mess since things are diffs. I
>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>>>>> that will get removed. Or perhaps the issues will arise on
>>>>>>>> filter-branch.
>>>>>>>> 
>>>>>>>> Will test now and reply in a moment.
>>>>>>>> 
>>>>>>>> Thanks!
>>>>>>>> steven
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>>>>> 
>>>>>>>>> Hi Steven
>>>>>>>>> 
>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>>>>> 
>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>> 
>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>>>>> I checked the parents
>>>>>>>>> 
>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>>>>> 
>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>>>>> removing it with git replace. Now I have
>>>>>>>>> 
>>>>>>>>> git rev-list --count HEAD
>>>>>>>>> 15049
>>>>>>>>> 
>>>>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>>>>> 
>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>>>>> maybe we need to cherry pick?
>>>>>>>>> 
>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>>>>> refs get removed, we get the whole messed history back.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> best
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>> 
>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>>>>> 
>>>>>>>>>> --oneline --ancestry-path 652633..
>>>>>>>>> 
>>>>>> 
>>>> 
>>> 

Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
> 
> Ops, only realised the dev2 branch was already there. I will make it develop2
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
>> 
>> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
>> 
>> 1) For the first two commits, I just replaced the merge as before
>> 
>> $ git replace --edit 4a7ea2c7e6
>> removing cc84b961d
>> $ git replace --edit 7894927615
>> removing e4ca0b12a
>> 
>> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07 
>> and found two commits back in the history that there was a duplicate
>> merge. 
>> 
>> The child of one of this duplicates is (two down from 2b6c5bffd)
>> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
>> 
>> the parent, one of the duplicate merges, is
>> 
>> 394c43edd0dd68f992647f51b00f78c33564987a
>> 
>> and the correct merge in the history was
>> 
>> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
>> 
>> So I edited 
>> $ git replace --edit 4e4721c9f85329
>> and replaced the first (39…) by the second (83...)
>> 
>> Now I have 15051 commits. I think we can apply 
>> filter-branch to this and it will fix the problem. You can
>> re-trace my steps above and verify it.
>> 
>> I have pushed a dev2 branch to which I applied
>> the filter so you can have a look at.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952 
>> 
>>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
>>> 
>>> Yes, please do give it a go if you have the time. (I'm a bit
>>> intermittent to get to most anything outside of work at the moment.)
>>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>>>> 
>>>> Btw, let me know if you want help with this.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>> 
>>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>>>>> 
>>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>>>>> commits we want to keep.
>>>>> 
>>>>> In any case,  if 1) works and we can always cherry pick.
>>>>> 
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952
>>>>> 
>>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>>>>>> 
>>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>>>>>> filter-branch now, but I'm wondering if there's a better way.  My
>>>>>> thought is:
>>>>>> 
>>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>>>>>> 
>>>>>> ...a -> b -> c -> merge commit ->
>>>>>> ...x-> q -> z ->   ---^
>>>>>> 
>>>>>> to just:
>>>>>> 
>>>>>> ...a -> b -> c -> merge commit ->
>>>>>> 
>>>>>> If we do that, maybe q and z are good commits we want, but x and
>>>>>> everything before is not. Here we were then talking about cherry
>>>>>> picking.
>>>>>> 
>>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>>>>>> interesting commit.  So for the above, maybe we edit q, change its
>>>>>> parent to c, then hopefully all is right, something like:
>>>>>> 
>>>>>> ...a -> b -> c ------->  merge commit ->
>>>>>>              \--> q -> z ->   ---^
>>>>>> 
>>>>>> 
>>>>>> Regarding the first path, I just tried running the filter branch with:
>>>>>> 
>>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>>>>>> seconds passed, remaining 0 predicted)
>>>>>> Ref 'refs/heads/develop' was rewritten
>>>>>> 
>>>>>> and got the above. I could then delete the entries in
>>>>>> .git/refs/replace and still have 15K entries.
>>>>>> 
>>>>>> 
>>>>>> I think we should try #2 next, as in my head it's sort of what we're
>>>>>> wanting in the end and seems more correct than trying to cherry-pick.
>>>>>> (Could use the same replace --edit command I think.) I've got a fair
>>>>>> amount of other work to do now, but will try to take a look later in
>>>>>> the day if you haven't gotten to it first.
>>>>>> 
>>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> I did three modifications:
>>>>>>> 
>>>>>>> 1) git replace --edit 4a7ea2c7e6
>>>>>>> 
>>>>>>> removing cc84b961d
>>>>>>> 
>>>>>>> 2) git replace --edit 7894927615
>>>>>>> 
>>>>>>> removing e4ca0b12a
>>>>>>> 
>>>>>>> 3) git replace —edit 2b6c5bffdd46e07
>>>>>>> 
>>>>>>> removing 00eb43efb
>>>>>>> 
>>>>>>> and ended up with 15k commits in HEAD.
>>>>>>> 
>>>>>>> 
>>>>>>> And yes I saw that paragraph at the time and it horrified me.
>>>>>>> 
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>> 
>>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>>>>>> other commits too?  I'm not sure what I might be doing differently
>>>>>>>> here locally.
>>>>>>>> 
>>>>>>>> I see that that commit was a merge from a pull request related to
>>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>>>>>> were a few other pull requests.
>>>>>>>> 
>>>>>>>> Side note, I saw this on the github page for removing sensitive data
>>>>>>>> from a git repository
>>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>>>>>> I think we used this when we did the VST-related change):
>>>>>>>> 
>>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>>>>>> created off of your old (tainted) repository history. One merge commit
>>>>>>>> could reintroduce some or all of the tainted history that you just
>>>>>>>> went to the trouble of purging."
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>>>>>> 
>>>>>>>>> Hi Victor,
>>>>>>>>> 
>>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>>>>>> just delete the entries in that folder.
>>>>>>>>> 
>>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>>>>>> 
>>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>>>>>> 
>>>>>>>>> and in the first reply it says you can make the change permanent using either:
>>>>>>>>> 
>>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>>>>>> 
>>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>>>>>> to see if that hasn't been cleared up.
>>>>>>>>> 
>>>>>>>>> I'll give that a try now here locally to see what happens and report
>>>>>>>>> back momentarily.  After that, my thought for the commit history that
>>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>>>>>> to me is that, by removing commits from history, I would have expected
>>>>>>>>> later commits to become something of a mess since things are diffs. I
>>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>>>>>> that will get removed. Or perhaps the issues will arise on
>>>>>>>>> filter-branch.
>>>>>>>>> 
>>>>>>>>> Will test now and reply in a moment.
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> steven
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Steven
>>>>>>>>>> 
>>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>>>>>> 
>>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>> 
>>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>>>>>> I checked the parents
>>>>>>>>>> 
>>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>>>>>> 
>>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>>>>>> removing it with git replace. Now I have
>>>>>>>>>> 
>>>>>>>>>> git rev-list --count HEAD
>>>>>>>>>> 15049
>>>>>>>>>> 
>>>>>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>>>>>> 
>>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>>>>>> maybe we need to cherry pick?
>>>>>>>>>> 
>>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>>>>>> refs get removed, we get the whole messed history back.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> best
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>> 
>>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> --oneline --ancestry-path 652633..
>>>>>>>>>> 
>>>>>>> 
>>>

I didn't try reproducing just looked at the dev2 branch (looks like
both dev2 and develop2 are on github now).  I did:

git diff dev2..develop

and the only file diffs it showed were for John's most recent commit.
I think if we cherry pick that, we're good.

It'd be good to get additional double-check since this is a big change
in a way and we're going to have to commit to it.  Felipe or Stephen,
could you perhaps take a look?

I think next steps would be:

1. Cherry-pick John's last commit from develop
2. Merge master into dev2 (so we can clean merge to master when do
release, and there's a merge conflict to fix if you try it locally)
3. Delete develop from remote
4. Re-push develop from local to remote as old-develop (let's keep it
around for short term)
5. Push dev2 to remote as develop

For everyone in the ecosystem, I'm not quite sure what the exact steps
are. We need to account for:

1. Developers and people with local git repos: Perhaps promote
deleting local repository and re-clone?
2. For github forks: not sure here? Some sort of rebase operation?



On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
>
> Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
> > On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
> >
> > Ops, only realised the dev2 branch was already there. I will make it develop2
> > ========================
> > Prof. Victor Lazzarini
> > Dean of Arts, Celtic Studies, and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> >> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
> >>
> >> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
> >>
> >> 1) For the first two commits, I just replaced the merge as before
> >>
> >> $ git replace --edit 4a7ea2c7e6
> >> removing cc84b961d
> >> $ git replace --edit 7894927615
> >> removing e4ca0b12a
> >>
> >> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
> >> and found two commits back in the history that there was a duplicate
> >> merge.
> >>
> >> The child of one of this duplicates is (two down from 2b6c5bffd)
> >> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
> >>
> >> the parent, one of the duplicate merges, is
> >>
> >> 394c43edd0dd68f992647f51b00f78c33564987a
> >>
> >> and the correct merge in the history was
> >>
> >> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
> >>
> >> So I edited
> >> $ git replace --edit 4e4721c9f85329
> >> and replaced the first (39…) by the second (83...)
> >>
> >> Now I have 15051 commits. I think we can apply
> >> filter-branch to this and it will fix the problem. You can
> >> re-trace my steps above and verify it.
> >>
> >> I have pushed a dev2 branch to which I applied
> >> the filter so you can have a look at.
> >> ========================
> >> Prof. Victor Lazzarini
> >> Dean of Arts, Celtic Studies, and Philosophy,
> >> Maynooth University,
> >> Maynooth, Co Kildare, Ireland
> >> Tel: 00 353 7086936
> >> Fax: 00 353 1 7086952
> >>
> >>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
> >>>
> >>> Yes, please do give it a go if you have the time. (I'm a bit
> >>> intermittent to get to most anything outside of work at the moment.)
> >>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
> >>>>
> >>>> Btw, let me know if you want help with this.
> >>>> ========================
> >>>> Prof. Victor Lazzarini
> >>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>> Maynooth University,
> >>>> Maynooth, Co Kildare, Ireland
> >>>> Tel: 00 353 7086936
> >>>> Fax: 00 353 1 7086952
> >>>>
> >>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
> >>>>>
> >>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
> >>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
> >>>>> commits we want to keep.
> >>>>>
> >>>>> In any case,  if 1) works and we can always cherry pick.
> >>>>>
> >>>>> ========================
> >>>>> Prof. Victor Lazzarini
> >>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>> Maynooth University,
> >>>>> Maynooth, Co Kildare, Ireland
> >>>>> Tel: 00 353 7086936
> >>>>> Fax: 00 353 1 7086952
> >>>>>
> >>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
> >>>>>>
> >>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
> >>>>>> filter-branch now, but I'm wondering if there's a better way.  My
> >>>>>> thought is:
> >>>>>>
> >>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
> >>>>>>
> >>>>>> ...a -> b -> c -> merge commit ->
> >>>>>> ...x-> q -> z ->   ---^
> >>>>>>
> >>>>>> to just:
> >>>>>>
> >>>>>> ...a -> b -> c -> merge commit ->
> >>>>>>
> >>>>>> If we do that, maybe q and z are good commits we want, but x and
> >>>>>> everything before is not. Here we were then talking about cherry
> >>>>>> picking.
> >>>>>>
> >>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
> >>>>>> interesting commit.  So for the above, maybe we edit q, change its
> >>>>>> parent to c, then hopefully all is right, something like:
> >>>>>>
> >>>>>> ...a -> b -> c ------->  merge commit ->
> >>>>>>              \--> q -> z ->   ---^
> >>>>>>
> >>>>>>
> >>>>>> Regarding the first path, I just tried running the filter branch with:
> >>>>>>
> >>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
> >>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
> >>>>>> seconds passed, remaining 0 predicted)
> >>>>>> Ref 'refs/heads/develop' was rewritten
> >>>>>>
> >>>>>> and got the above. I could then delete the entries in
> >>>>>> .git/refs/replace and still have 15K entries.
> >>>>>>
> >>>>>>
> >>>>>> I think we should try #2 next, as in my head it's sort of what we're
> >>>>>> wanting in the end and seems more correct than trying to cherry-pick.
> >>>>>> (Could use the same replace --edit command I think.) I've got a fair
> >>>>>> amount of other work to do now, but will try to take a look later in
> >>>>>> the day if you haven't gotten to it first.
> >>>>>>
> >>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
> >>>>>>>
> >>>>>>> I did three modifications:
> >>>>>>>
> >>>>>>> 1) git replace --edit 4a7ea2c7e6
> >>>>>>>
> >>>>>>> removing cc84b961d
> >>>>>>>
> >>>>>>> 2) git replace --edit 7894927615
> >>>>>>>
> >>>>>>> removing e4ca0b12a
> >>>>>>>
> >>>>>>> 3) git replace —edit 2b6c5bffdd46e07
> >>>>>>>
> >>>>>>> removing 00eb43efb
> >>>>>>>
> >>>>>>> and ended up with 15k commits in HEAD.
> >>>>>>>
> >>>>>>>
> >>>>>>> And yes I saw that paragraph at the time and it horrified me.
> >>>>>>>
> >>>>>>> ========================
> >>>>>>> Prof. Victor Lazzarini
> >>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>> Maynooth University,
> >>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>> Tel: 00 353 7086936
> >>>>>>> Fax: 00 353 1 7086952
> >>>>>>>
> >>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
> >>>>>>>>
> >>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
> >>>>>>>> other commits too?  I'm not sure what I might be doing differently
> >>>>>>>> here locally.
> >>>>>>>>
> >>>>>>>> I see that that commit was a merge from a pull request related to
> >>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
> >>>>>>>> were a few other pull requests.
> >>>>>>>>
> >>>>>>>> Side note, I saw this on the github page for removing sensitive data
> >>>>>>>> from a git repository
> >>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
> >>>>>>>> I think we used this when we did the VST-related change):
> >>>>>>>>
> >>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
> >>>>>>>> created off of your old (tainted) repository history. One merge commit
> >>>>>>>> could reintroduce some or all of the tainted history that you just
> >>>>>>>> went to the trouble of purging."
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
> >>>>>>>>>
> >>>>>>>>> Hi Victor,
> >>>>>>>>>
> >>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
> >>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
> >>>>>>>>> actually checked out a fresh copy of Csound before learning one could
> >>>>>>>>> just delete the entries in that folder.
> >>>>>>>>>
> >>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
> >>>>>>>>>
> >>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
> >>>>>>>>>
> >>>>>>>>> and in the first reply it says you can make the change permanent using either:
> >>>>>>>>>
> >>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
> >>>>>>>>>
> >>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
> >>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
> >>>>>>>>> to see if that hasn't been cleared up.
> >>>>>>>>>
> >>>>>>>>> I'll give that a try now here locally to see what happens and report
> >>>>>>>>> back momentarily.  After that, my thought for the commit history that
> >>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
> >>>>>>>>> to me is that, by removing commits from history, I would have expected
> >>>>>>>>> later commits to become something of a mess since things are diffs. I
> >>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
> >>>>>>>>> that will get removed. Or perhaps the issues will arise on
> >>>>>>>>> filter-branch.
> >>>>>>>>>
> >>>>>>>>> Will test now and reply in a moment.
> >>>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>> steven
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Steven
> >>>>>>>>>>
> >>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
> >>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
> >>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
> >>>>>>>>>>
> >>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>>>>>>>>
> >>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
> >>>>>>>>>> I checked the parents
> >>>>>>>>>>
> >>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
> >>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
> >>>>>>>>>>
> >>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
> >>>>>>>>>> removing it with git replace. Now I have
> >>>>>>>>>>
> >>>>>>>>>> git rev-list --count HEAD
> >>>>>>>>>> 15049
> >>>>>>>>>>
> >>>>>>>>>> So I think we found it. Two questions before we move to fix this:
> >>>>>>>>>>
> >>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
> >>>>>>>>>> maybe we need to cherry pick?
> >>>>>>>>>>
> >>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
> >>>>>>>>>> refs get removed, we get the whole messed history back.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> best
> >>>>>>>>>> ========================
> >>>>>>>>>> Prof. Victor Lazzarini
> >>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>>>>> Maynooth University,
> >>>>>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>>>>> Tel: 00 353 7086936
> >>>>>>>>>> Fax: 00 353 1 7086952
> >>>>>>>>>>
> >>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> --oneline --ancestry-path 652633..
> >>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>
> >

If that is the case, could we not just apply my method to develop? We could create a branch for safety and then go for it?

That is, instead of cherry picking.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 6 Sep 2018, at 13:45, Steven Yi  wrote:
> 
> I didn't try reproducing just looked at the dev2 branch (looks like
> both dev2 and develop2 are on github now).  I did:
> 
> git diff dev2..develop
> 
> and the only file diffs it showed were for John's most recent commit.
> I think if we cherry pick that, we're good.
> 
> It'd be good to get additional double-check since this is a big change
> in a way and we're going to have to commit to it.  Felipe or Stephen,
> could you perhaps take a look?
> 
> I think next steps would be:
> 
> 1. Cherry-pick John's last commit from develop
> 2. Merge master into dev2 (so we can clean merge to master when do
> release, and there's a merge conflict to fix if you try it locally)
> 3. Delete develop from remote
> 4. Re-push develop from local to remote as old-develop (let's keep it
> around for short term)
> 5. Push dev2 to remote as develop
> 
> For everyone in the ecosystem, I'm not quite sure what the exact steps
> are. We need to account for:
> 
> 1. Developers and people with local git repos: Perhaps promote
> deleting local repository and re-clone?
> 2. For github forks: not sure here? Some sort of rebase operation?
> 
> 
> 
>> On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
>> 
>> Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
>>> 
>>> Ops, only realised the dev2 branch was already there. I will make it develop2
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
>>>> 
>>>> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
>>>> 
>>>> 1) For the first two commits, I just replaced the merge as before
>>>> 
>>>> $ git replace --edit 4a7ea2c7e6
>>>> removing cc84b961d
>>>> $ git replace --edit 7894927615
>>>> removing e4ca0b12a
>>>> 
>>>> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
>>>> and found two commits back in the history that there was a duplicate
>>>> merge.
>>>> 
>>>> The child of one of this duplicates is (two down from 2b6c5bffd)
>>>> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
>>>> 
>>>> the parent, one of the duplicate merges, is
>>>> 
>>>> 394c43edd0dd68f992647f51b00f78c33564987a
>>>> 
>>>> and the correct merge in the history was
>>>> 
>>>> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
>>>> 
>>>> So I edited
>>>> $ git replace --edit 4e4721c9f85329
>>>> and replaced the first (39…) by the second (83...)
>>>> 
>>>> Now I have 15051 commits. I think we can apply
>>>> filter-branch to this and it will fix the problem. You can
>>>> re-trace my steps above and verify it.
>>>> 
>>>> I have pushed a dev2 branch to which I applied
>>>> the filter so you can have a look at.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>> 
>>>>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
>>>>> 
>>>>> Yes, please do give it a go if you have the time. (I'm a bit
>>>>> intermittent to get to most anything outside of work at the moment.)
>>>>>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Btw, let me know if you want help with this.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>> 
>>>>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>>>>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>>>>>>> commits we want to keep.
>>>>>>> 
>>>>>>> In any case,  if 1) works and we can always cherry pick.
>>>>>>> 
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>> 
>>>>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>>>>>>>> filter-branch now, but I'm wondering if there's a better way.  My
>>>>>>>> thought is:
>>>>>>>> 
>>>>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>>>>>>>> 
>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>> ...x-> q -> z ->   ---^
>>>>>>>> 
>>>>>>>> to just:
>>>>>>>> 
>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>> 
>>>>>>>> If we do that, maybe q and z are good commits we want, but x and
>>>>>>>> everything before is not. Here we were then talking about cherry
>>>>>>>> picking.
>>>>>>>> 
>>>>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>>>>>>>> interesting commit.  So for the above, maybe we edit q, change its
>>>>>>>> parent to c, then hopefully all is right, something like:
>>>>>>>> 
>>>>>>>> ...a -> b -> c ------->  merge commit ->
>>>>>>>>             \--> q -> z ->   ---^
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regarding the first path, I just tried running the filter branch with:
>>>>>>>> 
>>>>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>>>>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>>>>>>>> seconds passed, remaining 0 predicted)
>>>>>>>> Ref 'refs/heads/develop' was rewritten
>>>>>>>> 
>>>>>>>> and got the above. I could then delete the entries in
>>>>>>>> .git/refs/replace and still have 15K entries.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think we should try #2 next, as in my head it's sort of what we're
>>>>>>>> wanting in the end and seems more correct than trying to cherry-pick.
>>>>>>>> (Could use the same replace --edit command I think.) I've got a fair
>>>>>>>> amount of other work to do now, but will try to take a look later in
>>>>>>>> the day if you haven't gotten to it first.
>>>>>>>> 
>>>>>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>>>>>>>> 
>>>>>>>>> I did three modifications:
>>>>>>>>> 
>>>>>>>>> 1) git replace --edit 4a7ea2c7e6
>>>>>>>>> 
>>>>>>>>> removing cc84b961d
>>>>>>>>> 
>>>>>>>>> 2) git replace --edit 7894927615
>>>>>>>>> 
>>>>>>>>> removing e4ca0b12a
>>>>>>>>> 
>>>>>>>>> 3) git replace —edit 2b6c5bffdd46e07
>>>>>>>>> 
>>>>>>>>> removing 00eb43efb
>>>>>>>>> 
>>>>>>>>> and ended up with 15k commits in HEAD.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> And yes I saw that paragraph at the time and it horrified me.
>>>>>>>>> 
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>> 
>>>>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>>>>>>>> 
>>>>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>>>>>>>> other commits too?  I'm not sure what I might be doing differently
>>>>>>>>>> here locally.
>>>>>>>>>> 
>>>>>>>>>> I see that that commit was a merge from a pull request related to
>>>>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>>>>>>>> were a few other pull requests.
>>>>>>>>>> 
>>>>>>>>>> Side note, I saw this on the github page for removing sensitive data
>>>>>>>>>> from a git repository
>>>>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>>>>>>>> I think we used this when we did the VST-related change):
>>>>>>>>>> 
>>>>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>>>>>>>> created off of your old (tainted) repository history. One merge commit
>>>>>>>>>> could reintroduce some or all of the tainted history that you just
>>>>>>>>>> went to the trouble of purging."
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Victor,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>>>>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>>>>>>>> just delete the entries in that folder.
>>>>>>>>>>> 
>>>>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>>>>>>>> 
>>>>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>>>>>>>> 
>>>>>>>>>>> and in the first reply it says you can make the change permanent using either:
>>>>>>>>>>> 
>>>>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>>>>>>>> 
>>>>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>>>>>>>> to see if that hasn't been cleared up.
>>>>>>>>>>> 
>>>>>>>>>>> I'll give that a try now here locally to see what happens and report
>>>>>>>>>>> back momentarily.  After that, my thought for the commit history that
>>>>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>>>>>>>> to me is that, by removing commits from history, I would have expected
>>>>>>>>>>> later commits to become something of a mess since things are diffs. I
>>>>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>>>>>>>> that will get removed. Or perhaps the issues will arise on
>>>>>>>>>>> filter-branch.
>>>>>>>>>>> 
>>>>>>>>>>> Will test now and reply in a moment.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks!
>>>>>>>>>>> steven
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Steven
>>>>>>>>>>>> 
>>>>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>>>>>>>> 
>>>>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>>>> 
>>>>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>>>>>>>> I checked the parents
>>>>>>>>>>>> 
>>>>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>>>>>>>> 
>>>>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>>>>>>>> removing it with git replace. Now I have
>>>>>>>>>>>> 
>>>>>>>>>>>> git rev-list --count HEAD
>>>>>>>>>>>> 15049
>>>>>>>>>>>> 
>>>>>>>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>>>>>>>> maybe we need to cherry pick?
>>>>>>>>>>>> 
>>>>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>>>>>>>> refs get removed, we get the whole messed history back.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> best
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --oneline --ancestry-path 652633..
>>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>

That makes sense to not bother cherry-picking and redo the process
from latest develop to make life simpler.

How about in a local new clone:

1. reapply process in new local dev2
2. keep copy of local develop
3. delete origin/develop
4. push dev2 to origin/develop
5. push develop to origin/old-develop-bad

?

On Thu, Sep 6, 2018 at 8:49 AM Victor Lazzarini  wrote:
>
> If that is the case, could we not just apply my method to develop? We could create a branch for safety and then go for it?
>
> That is, instead of cherry picking.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> > On 6 Sep 2018, at 13:45, Steven Yi  wrote:
> >
> > I didn't try reproducing just looked at the dev2 branch (looks like
> > both dev2 and develop2 are on github now).  I did:
> >
> > git diff dev2..develop
> >
> > and the only file diffs it showed were for John's most recent commit.
> > I think if we cherry pick that, we're good.
> >
> > It'd be good to get additional double-check since this is a big change
> > in a way and we're going to have to commit to it.  Felipe or Stephen,
> > could you perhaps take a look?
> >
> > I think next steps would be:
> >
> > 1. Cherry-pick John's last commit from develop
> > 2. Merge master into dev2 (so we can clean merge to master when do
> > release, and there's a merge conflict to fix if you try it locally)
> > 3. Delete develop from remote
> > 4. Re-push develop from local to remote as old-develop (let's keep it
> > around for short term)
> > 5. Push dev2 to remote as develop
> >
> > For everyone in the ecosystem, I'm not quite sure what the exact steps
> > are. We need to account for:
> >
> > 1. Developers and people with local git repos: Perhaps promote
> > deleting local repository and re-clone?
> > 2. For github forks: not sure here? Some sort of rebase operation?
> >
> >
> >
> >> On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
> >>
> >> Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
> >> ========================
> >> Prof. Victor Lazzarini
> >> Dean of Arts, Celtic Studies, and Philosophy,
> >> Maynooth University,
> >> Maynooth, Co Kildare, Ireland
> >> Tel: 00 353 7086936
> >> Fax: 00 353 1 7086952
> >>
> >>> On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
> >>>
> >>> Ops, only realised the dev2 branch was already there. I will make it develop2
> >>> ========================
> >>> Prof. Victor Lazzarini
> >>> Dean of Arts, Celtic Studies, and Philosophy,
> >>> Maynooth University,
> >>> Maynooth, Co Kildare, Ireland
> >>> Tel: 00 353 7086936
> >>> Fax: 00 353 1 7086952
> >>>
> >>>> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
> >>>>
> >>>> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
> >>>>
> >>>> 1) For the first two commits, I just replaced the merge as before
> >>>>
> >>>> $ git replace --edit 4a7ea2c7e6
> >>>> removing cc84b961d
> >>>> $ git replace --edit 7894927615
> >>>> removing e4ca0b12a
> >>>>
> >>>> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
> >>>> and found two commits back in the history that there was a duplicate
> >>>> merge.
> >>>>
> >>>> The child of one of this duplicates is (two down from 2b6c5bffd)
> >>>> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
> >>>>
> >>>> the parent, one of the duplicate merges, is
> >>>>
> >>>> 394c43edd0dd68f992647f51b00f78c33564987a
> >>>>
> >>>> and the correct merge in the history was
> >>>>
> >>>> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
> >>>>
> >>>> So I edited
> >>>> $ git replace --edit 4e4721c9f85329
> >>>> and replaced the first (39…) by the second (83...)
> >>>>
> >>>> Now I have 15051 commits. I think we can apply
> >>>> filter-branch to this and it will fix the problem. You can
> >>>> re-trace my steps above and verify it.
> >>>>
> >>>> I have pushed a dev2 branch to which I applied
> >>>> the filter so you can have a look at.
> >>>> ========================
> >>>> Prof. Victor Lazzarini
> >>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>> Maynooth University,
> >>>> Maynooth, Co Kildare, Ireland
> >>>> Tel: 00 353 7086936
> >>>> Fax: 00 353 1 7086952
> >>>>
> >>>>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
> >>>>>
> >>>>> Yes, please do give it a go if you have the time. (I'm a bit
> >>>>> intermittent to get to most anything outside of work at the moment.)
> >>>>>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
> >>>>>>
> >>>>>> Btw, let me know if you want help with this.
> >>>>>> ========================
> >>>>>> Prof. Victor Lazzarini
> >>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>> Maynooth University,
> >>>>>> Maynooth, Co Kildare, Ireland
> >>>>>> Tel: 00 353 7086936
> >>>>>> Fax: 00 353 1 7086952
> >>>>>>
> >>>>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
> >>>>>>>
> >>>>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
> >>>>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
> >>>>>>> commits we want to keep.
> >>>>>>>
> >>>>>>> In any case,  if 1) works and we can always cherry pick.
> >>>>>>>
> >>>>>>> ========================
> >>>>>>> Prof. Victor Lazzarini
> >>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>> Maynooth University,
> >>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>> Tel: 00 353 7086936
> >>>>>>> Fax: 00 353 1 7086952
> >>>>>>>
> >>>>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
> >>>>>>>>
> >>>>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
> >>>>>>>> filter-branch now, but I'm wondering if there's a better way.  My
> >>>>>>>> thought is:
> >>>>>>>>
> >>>>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
> >>>>>>>>
> >>>>>>>> ...a -> b -> c -> merge commit ->
> >>>>>>>> ...x-> q -> z ->   ---^
> >>>>>>>>
> >>>>>>>> to just:
> >>>>>>>>
> >>>>>>>> ...a -> b -> c -> merge commit ->
> >>>>>>>>
> >>>>>>>> If we do that, maybe q and z are good commits we want, but x and
> >>>>>>>> everything before is not. Here we were then talking about cherry
> >>>>>>>> picking.
> >>>>>>>>
> >>>>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
> >>>>>>>> interesting commit.  So for the above, maybe we edit q, change its
> >>>>>>>> parent to c, then hopefully all is right, something like:
> >>>>>>>>
> >>>>>>>> ...a -> b -> c ------->  merge commit ->
> >>>>>>>>             \--> q -> z ->   ---^
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Regarding the first path, I just tried running the filter branch with:
> >>>>>>>>
> >>>>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
> >>>>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
> >>>>>>>> seconds passed, remaining 0 predicted)
> >>>>>>>> Ref 'refs/heads/develop' was rewritten
> >>>>>>>>
> >>>>>>>> and got the above. I could then delete the entries in
> >>>>>>>> .git/refs/replace and still have 15K entries.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I think we should try #2 next, as in my head it's sort of what we're
> >>>>>>>> wanting in the end and seems more correct than trying to cherry-pick.
> >>>>>>>> (Could use the same replace --edit command I think.) I've got a fair
> >>>>>>>> amount of other work to do now, but will try to take a look later in
> >>>>>>>> the day if you haven't gotten to it first.
> >>>>>>>>
> >>>>>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
> >>>>>>>>>
> >>>>>>>>> I did three modifications:
> >>>>>>>>>
> >>>>>>>>> 1) git replace --edit 4a7ea2c7e6
> >>>>>>>>>
> >>>>>>>>> removing cc84b961d
> >>>>>>>>>
> >>>>>>>>> 2) git replace --edit 7894927615
> >>>>>>>>>
> >>>>>>>>> removing e4ca0b12a
> >>>>>>>>>
> >>>>>>>>> 3) git replace —edit 2b6c5bffdd46e07
> >>>>>>>>>
> >>>>>>>>> removing 00eb43efb
> >>>>>>>>>
> >>>>>>>>> and ended up with 15k commits in HEAD.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> And yes I saw that paragraph at the time and it horrified me.
> >>>>>>>>>
> >>>>>>>>> ========================
> >>>>>>>>> Prof. Victor Lazzarini
> >>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>>>> Maynooth University,
> >>>>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>>>> Tel: 00 353 7086936
> >>>>>>>>> Fax: 00 353 1 7086952
> >>>>>>>>>
> >>>>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
> >>>>>>>>>>
> >>>>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
> >>>>>>>>>> other commits too?  I'm not sure what I might be doing differently
> >>>>>>>>>> here locally.
> >>>>>>>>>>
> >>>>>>>>>> I see that that commit was a merge from a pull request related to
> >>>>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
> >>>>>>>>>> were a few other pull requests.
> >>>>>>>>>>
> >>>>>>>>>> Side note, I saw this on the github page for removing sensitive data
> >>>>>>>>>> from a git repository
> >>>>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
> >>>>>>>>>> I think we used this when we did the VST-related change):
> >>>>>>>>>>
> >>>>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
> >>>>>>>>>> created off of your old (tainted) repository history. One merge commit
> >>>>>>>>>> could reintroduce some or all of the tainted history that you just
> >>>>>>>>>> went to the trouble of purging."
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Victor,
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
> >>>>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
> >>>>>>>>>>> actually checked out a fresh copy of Csound before learning one could
> >>>>>>>>>>> just delete the entries in that folder.
> >>>>>>>>>>>
> >>>>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
> >>>>>>>>>>>
> >>>>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
> >>>>>>>>>>>
> >>>>>>>>>>> and in the first reply it says you can make the change permanent using either:
> >>>>>>>>>>>
> >>>>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
> >>>>>>>>>>>
> >>>>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
> >>>>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
> >>>>>>>>>>> to see if that hasn't been cleared up.
> >>>>>>>>>>>
> >>>>>>>>>>> I'll give that a try now here locally to see what happens and report
> >>>>>>>>>>> back momentarily.  After that, my thought for the commit history that
> >>>>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
> >>>>>>>>>>> to me is that, by removing commits from history, I would have expected
> >>>>>>>>>>> later commits to become something of a mess since things are diffs. I
> >>>>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
> >>>>>>>>>>> that will get removed. Or perhaps the issues will arise on
> >>>>>>>>>>> filter-branch.
> >>>>>>>>>>>
> >>>>>>>>>>> Will test now and reply in a moment.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks!
> >>>>>>>>>>> steven
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Steven
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
> >>>>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
> >>>>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>>>>>>>>>>
> >>>>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
> >>>>>>>>>>>> I checked the parents
> >>>>>>>>>>>>
> >>>>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
> >>>>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
> >>>>>>>>>>>>
> >>>>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
> >>>>>>>>>>>> removing it with git replace. Now I have
> >>>>>>>>>>>>
> >>>>>>>>>>>> git rev-list --count HEAD
> >>>>>>>>>>>> 15049
> >>>>>>>>>>>>
> >>>>>>>>>>>> So I think we found it. Two questions before we move to fix this:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
> >>>>>>>>>>>> maybe we need to cherry pick?
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
> >>>>>>>>>>>> refs get removed, we get the whole messed history back.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> best
> >>>>>>>>>>>> ========================
> >>>>>>>>>>>> Prof. Victor Lazzarini
> >>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>>>>>>> Maynooth University,
> >>>>>>>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>>>>>>> Tel: 00 353 7086936
> >>>>>>>>>>>> Fax: 00 353 1 7086952
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --oneline --ancestry-path 652633..
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>

Thanks Felipe for chiming in, your expertise makes me feel better
about all of this. :)

I suppose one additional step is to make a Wiki page on Github so that
we can direct everyone to it, as well as push a news story to the
csound.com site to make sure as much as possible that everyone knows
what to do.
On Thu, Sep 6, 2018 at 9:21 AM Felipe Sateler  wrote:
>
> I think it looks good. Commit fd612069831693 is no longer reachable from dev2 (while reachable from develop).
>
> Here's what I suggest people do for different cases:
>
> 1. I just track upstream development, don't do development myself: Get a fresh clone.
> 2. I have some branches that are still not merged into the mainline: You need to rebase:
>
> git checkout my-branch
> git rebase 12dff2cac --onto=fba8a20687b7
>
> (The first hash is current [borked] develop. The last commit is the current dev2 tip. If there is another rewrite, this last hash needs to change).
>
> 3. I have a fork on github: You need to overwrite the old history. For each branch you have fixed via 1. or 2., you need to `git push --force` back to your repo. Then you need to delete the tags in your repo. Assuming it is called 'origin':
>
> git tag | xargs git push --delete origin
> git tag | xargs git tag -d
>
> The tags will be re-downloaded the next time you pull from the upstream repository.
>
> On Thu, Sep 6, 2018 at 9:44 AM Steven Yi  wrote:
>>
>> I didn't try reproducing just looked at the dev2 branch (looks like
>> both dev2 and develop2 are on github now).  I did:
>>
>> git diff dev2..develop
>>
>> and the only file diffs it showed were for John's most recent commit.
>> I think if we cherry pick that, we're good.
>>
>> It'd be good to get additional double-check since this is a big change
>> in a way and we're going to have to commit to it.  Felipe or Stephen,
>> could you perhaps take a look?
>>
>> I think next steps would be:
>>
>> 1. Cherry-pick John's last commit from develop
>> 2. Merge master into dev2 (so we can clean merge to master when do
>> release, and there's a merge conflict to fix if you try it locally)
>> 3. Delete develop from remote
>> 4. Re-push develop from local to remote as old-develop (let's keep it
>> around for short term)
>> 5. Push dev2 to remote as develop
>>
>> For everyone in the ecosystem, I'm not quite sure what the exact steps
>> are. We need to account for:
>>
>> 1. Developers and people with local git repos: Perhaps promote
>> deleting local repository and re-clone?
>> 2. For github forks: not sure here? Some sort of rebase operation?
>>
>>
>>
>> On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
>> >
>> > Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
>> > ========================
>> > Prof. Victor Lazzarini
>> > Dean of Arts, Celtic Studies, and Philosophy,
>> > Maynooth University,
>> > Maynooth, Co Kildare, Ireland
>> > Tel: 00 353 7086936
>> > Fax: 00 353 1 7086952
>> >
>> > > On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
>> > >
>> > > Ops, only realised the dev2 branch was already there. I will make it develop2
>> > > ========================
>> > > Prof. Victor Lazzarini
>> > > Dean of Arts, Celtic Studies, and Philosophy,
>> > > Maynooth University,
>> > > Maynooth, Co Kildare, Ireland
>> > > Tel: 00 353 7086936
>> > > Fax: 00 353 1 7086952
>> > >
>> > >> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
>> > >>
>> > >> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
>> > >>
>> > >> 1) For the first two commits, I just replaced the merge as before
>> > >>
>> > >> $ git replace --edit 4a7ea2c7e6
>> > >> removing cc84b961d
>> > >> $ git replace --edit 7894927615
>> > >> removing e4ca0b12a
>> > >>
>> > >> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
>> > >> and found two commits back in the history that there was a duplicate
>> > >> merge.
>> > >>
>> > >> The child of one of this duplicates is (two down from 2b6c5bffd)
>> > >> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
>> > >>
>> > >> the parent, one of the duplicate merges, is
>> > >>
>> > >> 394c43edd0dd68f992647f51b00f78c33564987a
>> > >>
>> > >> and the correct merge in the history was
>> > >>
>> > >> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
>> > >>
>> > >> So I edited
>> > >> $ git replace --edit 4e4721c9f85329
>> > >> and replaced the first (39…) by the second (83...)
>> > >>
>> > >> Now I have 15051 commits. I think we can apply
>> > >> filter-branch to this and it will fix the problem. You can
>> > >> re-trace my steps above and verify it.
>> > >>
>> > >> I have pushed a dev2 branch to which I applied
>> > >> the filter so you can have a look at.
>> > >> ========================
>> > >> Prof. Victor Lazzarini
>> > >> Dean of Arts, Celtic Studies, and Philosophy,
>> > >> Maynooth University,
>> > >> Maynooth, Co Kildare, Ireland
>> > >> Tel: 00 353 7086936
>> > >> Fax: 00 353 1 7086952
>> > >>
>> > >>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
>> > >>>
>> > >>> Yes, please do give it a go if you have the time. (I'm a bit
>> > >>> intermittent to get to most anything outside of work at the moment.)
>> > >>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>> > >>>>
>> > >>>> Btw, let me know if you want help with this.
>> > >>>> ========================
>> > >>>> Prof. Victor Lazzarini
>> > >>>> Dean of Arts, Celtic Studies, and Philosophy,
>> > >>>> Maynooth University,
>> > >>>> Maynooth, Co Kildare, Ireland
>> > >>>> Tel: 00 353 7086936
>> > >>>> Fax: 00 353 1 7086952
>> > >>>>
>> > >>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>> > >>>>>
>> > >>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>> > >>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>> > >>>>> commits we want to keep.
>> > >>>>>
>> > >>>>> In any case,  if 1) works and we can always cherry pick.
>> > >>>>>
>> > >>>>> ========================
>> > >>>>> Prof. Victor Lazzarini
>> > >>>>> Dean of Arts, Celtic Studies, and Philosophy,
>> > >>>>> Maynooth University,
>> > >>>>> Maynooth, Co Kildare, Ireland
>> > >>>>> Tel: 00 353 7086936
>> > >>>>> Fax: 00 353 1 7086952
>> > >>>>>
>> > >>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>> > >>>>>>
>> > >>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>> > >>>>>> filter-branch now, but I'm wondering if there's a better way.  My
>> > >>>>>> thought is:
>> > >>>>>>
>> > >>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>> > >>>>>>
>> > >>>>>> ...a -> b -> c -> merge commit ->
>> > >>>>>> ...x-> q -> z ->   ---^
>> > >>>>>>
>> > >>>>>> to just:
>> > >>>>>>
>> > >>>>>> ...a -> b -> c -> merge commit ->
>> > >>>>>>
>> > >>>>>> If we do that, maybe q and z are good commits we want, but x and
>> > >>>>>> everything before is not. Here we were then talking about cherry
>> > >>>>>> picking.
>> > >>>>>>
>> > >>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>> > >>>>>> interesting commit.  So for the above, maybe we edit q, change its
>> > >>>>>> parent to c, then hopefully all is right, something like:
>> > >>>>>>
>> > >>>>>> ...a -> b -> c ------->  merge commit ->
>> > >>>>>>              \--> q -> z ->   ---^
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Regarding the first path, I just tried running the filter branch with:
>> > >>>>>>
>> > >>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>> > >>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>> > >>>>>> seconds passed, remaining 0 predicted)
>> > >>>>>> Ref 'refs/heads/develop' was rewritten
>> > >>>>>>
>> > >>>>>> and got the above. I could then delete the entries in
>> > >>>>>> .git/refs/replace and still have 15K entries.
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> I think we should try #2 next, as in my head it's sort of what we're
>> > >>>>>> wanting in the end and seems more correct than trying to cherry-pick.
>> > >>>>>> (Could use the same replace --edit command I think.) I've got a fair
>> > >>>>>> amount of other work to do now, but will try to take a look later in
>> > >>>>>> the day if you haven't gotten to it first.
>> > >>>>>>
>> > >>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>> > >>>>>>>
>> > >>>>>>> I did three modifications:
>> > >>>>>>>
>> > >>>>>>> 1) git replace --edit 4a7ea2c7e6
>> > >>>>>>>
>> > >>>>>>> removing cc84b961d
>> > >>>>>>>
>> > >>>>>>> 2) git replace --edit 7894927615
>> > >>>>>>>
>> > >>>>>>> removing e4ca0b12a
>> > >>>>>>>
>> > >>>>>>> 3) git replace —edit 2b6c5bffdd46e07
>> > >>>>>>>
>> > >>>>>>> removing 00eb43efb
>> > >>>>>>>
>> > >>>>>>> and ended up with 15k commits in HEAD.
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>> And yes I saw that paragraph at the time and it horrified me.
>> > >>>>>>>
>> > >>>>>>> ========================
>> > >>>>>>> Prof. Victor Lazzarini
>> > >>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>> > >>>>>>> Maynooth University,
>> > >>>>>>> Maynooth, Co Kildare, Ireland
>> > >>>>>>> Tel: 00 353 7086936
>> > >>>>>>> Fax: 00 353 1 7086952
>> > >>>>>>>
>> > >>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>> > >>>>>>>>
>> > >>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>> > >>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>> > >>>>>>>> other commits too?  I'm not sure what I might be doing differently
>> > >>>>>>>> here locally.
>> > >>>>>>>>
>> > >>>>>>>> I see that that commit was a merge from a pull request related to
>> > >>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>> > >>>>>>>> were a few other pull requests.
>> > >>>>>>>>
>> > >>>>>>>> Side note, I saw this on the github page for removing sensitive data
>> > >>>>>>>> from a git repository
>> > >>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>> > >>>>>>>> I think we used this when we did the VST-related change):
>> > >>>>>>>>
>> > >>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>> > >>>>>>>> created off of your old (tainted) repository history. One merge commit
>> > >>>>>>>> could reintroduce some or all of the tainted history that you just
>> > >>>>>>>> went to the trouble of purging."
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>> > >>>>>>>>>
>> > >>>>>>>>> Hi Victor,
>> > >>>>>>>>>
>> > >>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>> > >>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>> > >>>>>>>>> actually checked out a fresh copy of Csound before learning one could
>> > >>>>>>>>> just delete the entries in that folder.
>> > >>>>>>>>>
>> > >>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>> > >>>>>>>>>
>> > >>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>> > >>>>>>>>>
>> > >>>>>>>>> and in the first reply it says you can make the change permanent using either:
>> > >>>>>>>>>
>> > >>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>> > >>>>>>>>>
>> > >>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>> > >>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>> > >>>>>>>>> to see if that hasn't been cleared up.
>> > >>>>>>>>>
>> > >>>>>>>>> I'll give that a try now here locally to see what happens and report
>> > >>>>>>>>> back momentarily.  After that, my thought for the commit history that
>> > >>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>> > >>>>>>>>> to me is that, by removing commits from history, I would have expected
>> > >>>>>>>>> later commits to become something of a mess since things are diffs. I
>> > >>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>> > >>>>>>>>> that will get removed. Or perhaps the issues will arise on
>> > >>>>>>>>> filter-branch.
>> > >>>>>>>>>
>> > >>>>>>>>> Will test now and reply in a moment.
>> > >>>>>>>>>
>> > >>>>>>>>> Thanks!
>> > >>>>>>>>> steven
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>> > >>>>>>>>>>
>> > >>>>>>>>>> Hi Steven
>> > >>>>>>>>>>
>> > >>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>> > >>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>> > >>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>> > >>>>>>>>>>
>> > >>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>> > >>>>>>>>>>
>> > >>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>> > >>>>>>>>>> I checked the parents
>> > >>>>>>>>>>
>> > >>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>> > >>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>> > >>>>>>>>>>
>> > >>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>> > >>>>>>>>>> removing it with git replace. Now I have
>> > >>>>>>>>>>
>> > >>>>>>>>>> git rev-list --count HEAD
>> > >>>>>>>>>> 15049
>> > >>>>>>>>>>
>> > >>>>>>>>>> So I think we found it. Two questions before we move to fix this:
>> > >>>>>>>>>>
>> > >>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>> > >>>>>>>>>> maybe we need to cherry pick?
>> > >>>>>>>>>>
>> > >>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>> > >>>>>>>>>> refs get removed, we get the whole messed history back.
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> best
>> > >>>>>>>>>> ========================
>> > >>>>>>>>>> Prof. Victor Lazzarini
>> > >>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>> > >>>>>>>>>> Maynooth University,
>> > >>>>>>>>>> Maynooth, Co Kildare, Ireland
>> > >>>>>>>>>> Tel: 00 353 7086936
>> > >>>>>>>>>> Fax: 00 353 1 7086952
>> > >>>>>>>>>>
>> > >>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> --oneline --ancestry-path 652633..
>> > >>>>>>>>>>
>> > >>>>>>>
>> > >>>>>
>> > >>>>
>> > >>
>> > >
>> >
>
>
>
> --
>
> Saludos,

yes, but I would suggest a slight simplification

1) pull latest from develop
2) create a branch locally to old-develop
3) apply process to develop 
4) push it
5) push old-develop to origin

========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Sep 2018, at 14:52, Steven Yi  wrote:
> 
> That makes sense to not bother cherry-picking and redo the process
> from latest develop to make life simpler.
> 
> How about in a local new clone:
> 
> 1. reapply process in new local dev2
> 2. keep copy of local develop
> 3. delete origin/develop
> 4. push dev2 to origin/develop
> 5. push develop to origin/old-develop-bad
> 
> ?
> 
> On Thu, Sep 6, 2018 at 8:49 AM Victor Lazzarini  wrote:
>> 
>> If that is the case, could we not just apply my method to develop? We could create a branch for safety and then go for it?
>> 
>> That is, instead of cherry picking.
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>>> On 6 Sep 2018, at 13:45, Steven Yi  wrote:
>>> 
>>> I didn't try reproducing just looked at the dev2 branch (looks like
>>> both dev2 and develop2 are on github now).  I did:
>>> 
>>> git diff dev2..develop
>>> 
>>> and the only file diffs it showed were for John's most recent commit.
>>> I think if we cherry pick that, we're good.
>>> 
>>> It'd be good to get additional double-check since this is a big change
>>> in a way and we're going to have to commit to it.  Felipe or Stephen,
>>> could you perhaps take a look?
>>> 
>>> I think next steps would be:
>>> 
>>> 1. Cherry-pick John's last commit from develop
>>> 2. Merge master into dev2 (so we can clean merge to master when do
>>> release, and there's a merge conflict to fix if you try it locally)
>>> 3. Delete develop from remote
>>> 4. Re-push develop from local to remote as old-develop (let's keep it
>>> around for short term)
>>> 5. Push dev2 to remote as develop
>>> 
>>> For everyone in the ecosystem, I'm not quite sure what the exact steps
>>> are. We need to account for:
>>> 
>>> 1. Developers and people with local git repos: Perhaps promote
>>> deleting local repository and re-clone?
>>> 2. For github forks: not sure here? Some sort of rebase operation?
>>> 
>>> 
>>> 
>>>> On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
>>>> 
>>>> Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>> 
>>>>> On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
>>>>> 
>>>>> Ops, only realised the dev2 branch was already there. I will make it develop2
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952
>>>>> 
>>>>>> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
>>>>>> 
>>>>>> 1) For the first two commits, I just replaced the merge as before
>>>>>> 
>>>>>> $ git replace --edit 4a7ea2c7e6
>>>>>> removing cc84b961d
>>>>>> $ git replace --edit 7894927615
>>>>>> removing e4ca0b12a
>>>>>> 
>>>>>> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
>>>>>> and found two commits back in the history that there was a duplicate
>>>>>> merge.
>>>>>> 
>>>>>> The child of one of this duplicates is (two down from 2b6c5bffd)
>>>>>> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
>>>>>> 
>>>>>> the parent, one of the duplicate merges, is
>>>>>> 
>>>>>> 394c43edd0dd68f992647f51b00f78c33564987a
>>>>>> 
>>>>>> and the correct merge in the history was
>>>>>> 
>>>>>> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
>>>>>> 
>>>>>> So I edited
>>>>>> $ git replace --edit 4e4721c9f85329
>>>>>> and replaced the first (39…) by the second (83...)
>>>>>> 
>>>>>> Now I have 15051 commits. I think we can apply
>>>>>> filter-branch to this and it will fix the problem. You can
>>>>>> re-trace my steps above and verify it.
>>>>>> 
>>>>>> I have pushed a dev2 branch to which I applied
>>>>>> the filter so you can have a look at.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>> 
>>>>>>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
>>>>>>> 
>>>>>>> Yes, please do give it a go if you have the time. (I'm a bit
>>>>>>> intermittent to get to most anything outside of work at the moment.)
>>>>>>>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> Btw, let me know if you want help with this.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>> 
>>>>>>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>>>>>>>>> 
>>>>>>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>>>>>>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>>>>>>>>> commits we want to keep.
>>>>>>>>> 
>>>>>>>>> In any case,  if 1) works and we can always cherry pick.
>>>>>>>>> 
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>> 
>>>>>>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>>>>>>>>>> 
>>>>>>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>>>>>>>>>> filter-branch now, but I'm wondering if there's a better way.  My
>>>>>>>>>> thought is:
>>>>>>>>>> 
>>>>>>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>>>>>>>>>> 
>>>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>>>> ...x-> q -> z ->   ---^
>>>>>>>>>> 
>>>>>>>>>> to just:
>>>>>>>>>> 
>>>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>>>> 
>>>>>>>>>> If we do that, maybe q and z are good commits we want, but x and
>>>>>>>>>> everything before is not. Here we were then talking about cherry
>>>>>>>>>> picking.
>>>>>>>>>> 
>>>>>>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>>>>>>>>>> interesting commit.  So for the above, maybe we edit q, change its
>>>>>>>>>> parent to c, then hopefully all is right, something like:
>>>>>>>>>> 
>>>>>>>>>> ...a -> b -> c ------->  merge commit ->
>>>>>>>>>>            \--> q -> z ->   ---^
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Regarding the first path, I just tried running the filter branch with:
>>>>>>>>>> 
>>>>>>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>>>>>>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>>>>>>>>>> seconds passed, remaining 0 predicted)
>>>>>>>>>> Ref 'refs/heads/develop' was rewritten
>>>>>>>>>> 
>>>>>>>>>> and got the above. I could then delete the entries in
>>>>>>>>>> .git/refs/replace and still have 15K entries.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I think we should try #2 next, as in my head it's sort of what we're
>>>>>>>>>> wanting in the end and seems more correct than trying to cherry-pick.
>>>>>>>>>> (Could use the same replace --edit command I think.) I've got a fair
>>>>>>>>>> amount of other work to do now, but will try to take a look later in
>>>>>>>>>> the day if you haven't gotten to it first.
>>>>>>>>>> 
>>>>>>>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I did three modifications:
>>>>>>>>>>> 
>>>>>>>>>>> 1) git replace --edit 4a7ea2c7e6
>>>>>>>>>>> 
>>>>>>>>>>> removing cc84b961d
>>>>>>>>>>> 
>>>>>>>>>>> 2) git replace --edit 7894927615
>>>>>>>>>>> 
>>>>>>>>>>> removing e4ca0b12a
>>>>>>>>>>> 
>>>>>>>>>>> 3) git replace —edit 2b6c5bffdd46e07
>>>>>>>>>>> 
>>>>>>>>>>> removing 00eb43efb
>>>>>>>>>>> 
>>>>>>>>>>> and ended up with 15k commits in HEAD.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> And yes I saw that paragraph at the time and it horrified me.
>>>>>>>>>>> 
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>> 
>>>>>>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>>>>>>>>>> other commits too?  I'm not sure what I might be doing differently
>>>>>>>>>>>> here locally.
>>>>>>>>>>>> 
>>>>>>>>>>>> I see that that commit was a merge from a pull request related to
>>>>>>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>>>>>>>>>> were a few other pull requests.
>>>>>>>>>>>> 
>>>>>>>>>>>> Side note, I saw this on the github page for removing sensitive data
>>>>>>>>>>>> from a git repository
>>>>>>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>>>>>>>>>> I think we used this when we did the VST-related change):
>>>>>>>>>>>> 
>>>>>>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>>>>>>>>>> created off of your old (tainted) repository history. One merge commit
>>>>>>>>>>>> could reintroduce some or all of the tainted history that you just
>>>>>>>>>>>> went to the trouble of purging."
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Victor,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>>>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>>>>>>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>>>>>>>>>> just delete the entries in that folder.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>>>>>>>>>> 
>>>>>>>>>>>>> and in the first reply it says you can make the change permanent using either:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>>>>>>>>>> 
>>>>>>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>>>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>>>>>>>>>> to see if that hasn't been cleared up.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'll give that a try now here locally to see what happens and report
>>>>>>>>>>>>> back momentarily.  After that, my thought for the commit history that
>>>>>>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>>>>>>>>>> to me is that, by removing commits from history, I would have expected
>>>>>>>>>>>>> later commits to become something of a mess since things are diffs. I
>>>>>>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>>>>>>>>>> that will get removed. Or perhaps the issues will arise on
>>>>>>>>>>>>> filter-branch.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Will test now and reply in a moment.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>> steven
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Steven
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>>>>>>>>>> I checked the parents
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>>>>>>>>>> removing it with git replace. Now I have
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> git rev-list --count HEAD
>>>>>>>>>>>>>> 15049
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>>>>>>>>>> maybe we need to cherry pick?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>>>>>>>>>> refs get removed, we get the whole messed history back.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> best
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --oneline --ancestry-path 652633..
>>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 

I think we're on the same page and will get the same results either
way. I think we should go for it now and move on to the Wiki and
announcements after that.
On Thu, Sep 6, 2018 at 9:57 AM Victor Lazzarini  wrote:
>
> yes, but I would suggest a slight simplification
>
> 1) pull latest from develop
> 2) create a branch locally to old-develop
> 3) apply process to develop
> 4) push it
> 5) push old-develop to origin
>
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
> > On 6 Sep 2018, at 14:52, Steven Yi  wrote:
> >
> > That makes sense to not bother cherry-picking and redo the process
> > from latest develop to make life simpler.
> >
> > How about in a local new clone:
> >
> > 1. reapply process in new local dev2
> > 2. keep copy of local develop
> > 3. delete origin/develop
> > 4. push dev2 to origin/develop
> > 5. push develop to origin/old-develop-bad
> >
> > ?
> >
> > On Thu, Sep 6, 2018 at 8:49 AM Victor Lazzarini  wrote:
> >>
> >> If that is the case, could we not just apply my method to develop? We could create a branch for safety and then go for it?
> >>
> >> That is, instead of cherry picking.
> >>
> >> Victor Lazzarini
> >> Dean of Arts, Celtic Studies, and Philosophy
> >> Maynooth University
> >> Ireland
> >>
> >>> On 6 Sep 2018, at 13:45, Steven Yi  wrote:
> >>>
> >>> I didn't try reproducing just looked at the dev2 branch (looks like
> >>> both dev2 and develop2 are on github now).  I did:
> >>>
> >>> git diff dev2..develop
> >>>
> >>> and the only file diffs it showed were for John's most recent commit.
> >>> I think if we cherry pick that, we're good.
> >>>
> >>> It'd be good to get additional double-check since this is a big change
> >>> in a way and we're going to have to commit to it.  Felipe or Stephen,
> >>> could you perhaps take a look?
> >>>
> >>> I think next steps would be:
> >>>
> >>> 1. Cherry-pick John's last commit from develop
> >>> 2. Merge master into dev2 (so we can clean merge to master when do
> >>> release, and there's a merge conflict to fix if you try it locally)
> >>> 3. Delete develop from remote
> >>> 4. Re-push develop from local to remote as old-develop (let's keep it
> >>> around for short term)
> >>> 5. Push dev2 to remote as develop
> >>>
> >>> For everyone in the ecosystem, I'm not quite sure what the exact steps
> >>> are. We need to account for:
> >>>
> >>> 1. Developers and people with local git repos: Perhaps promote
> >>> deleting local repository and re-clone?
> >>> 2. For github forks: not sure here? Some sort of rebase operation?
> >>>
> >>>
> >>>
> >>>> On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
> >>>>
> >>>> Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
> >>>> ========================
> >>>> Prof. Victor Lazzarini
> >>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>> Maynooth University,
> >>>> Maynooth, Co Kildare, Ireland
> >>>> Tel: 00 353 7086936
> >>>> Fax: 00 353 1 7086952
> >>>>
> >>>>> On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
> >>>>>
> >>>>> Ops, only realised the dev2 branch was already there. I will make it develop2
> >>>>> ========================
> >>>>> Prof. Victor Lazzarini
> >>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>> Maynooth University,
> >>>>> Maynooth, Co Kildare, Ireland
> >>>>> Tel: 00 353 7086936
> >>>>> Fax: 00 353 1 7086952
> >>>>>
> >>>>>> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
> >>>>>>
> >>>>>> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
> >>>>>>
> >>>>>> 1) For the first two commits, I just replaced the merge as before
> >>>>>>
> >>>>>> $ git replace --edit 4a7ea2c7e6
> >>>>>> removing cc84b961d
> >>>>>> $ git replace --edit 7894927615
> >>>>>> removing e4ca0b12a
> >>>>>>
> >>>>>> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
> >>>>>> and found two commits back in the history that there was a duplicate
> >>>>>> merge.
> >>>>>>
> >>>>>> The child of one of this duplicates is (two down from 2b6c5bffd)
> >>>>>> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
> >>>>>>
> >>>>>> the parent, one of the duplicate merges, is
> >>>>>>
> >>>>>> 394c43edd0dd68f992647f51b00f78c33564987a
> >>>>>>
> >>>>>> and the correct merge in the history was
> >>>>>>
> >>>>>> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
> >>>>>>
> >>>>>> So I edited
> >>>>>> $ git replace --edit 4e4721c9f85329
> >>>>>> and replaced the first (39…) by the second (83...)
> >>>>>>
> >>>>>> Now I have 15051 commits. I think we can apply
> >>>>>> filter-branch to this and it will fix the problem. You can
> >>>>>> re-trace my steps above and verify it.
> >>>>>>
> >>>>>> I have pushed a dev2 branch to which I applied
> >>>>>> the filter so you can have a look at.
> >>>>>> ========================
> >>>>>> Prof. Victor Lazzarini
> >>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>> Maynooth University,
> >>>>>> Maynooth, Co Kildare, Ireland
> >>>>>> Tel: 00 353 7086936
> >>>>>> Fax: 00 353 1 7086952
> >>>>>>
> >>>>>>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
> >>>>>>>
> >>>>>>> Yes, please do give it a go if you have the time. (I'm a bit
> >>>>>>> intermittent to get to most anything outside of work at the moment.)
> >>>>>>>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
> >>>>>>>>
> >>>>>>>> Btw, let me know if you want help with this.
> >>>>>>>> ========================
> >>>>>>>> Prof. Victor Lazzarini
> >>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>>> Maynooth University,
> >>>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>>> Tel: 00 353 7086936
> >>>>>>>> Fax: 00 353 1 7086952
> >>>>>>>>
> >>>>>>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
> >>>>>>>>>
> >>>>>>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
> >>>>>>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
> >>>>>>>>> commits we want to keep.
> >>>>>>>>>
> >>>>>>>>> In any case,  if 1) works and we can always cherry pick.
> >>>>>>>>>
> >>>>>>>>> ========================
> >>>>>>>>> Prof. Victor Lazzarini
> >>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>>>> Maynooth University,
> >>>>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>>>> Tel: 00 353 7086936
> >>>>>>>>> Fax: 00 353 1 7086952
> >>>>>>>>>
> >>>>>>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
> >>>>>>>>>>
> >>>>>>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
> >>>>>>>>>> filter-branch now, but I'm wondering if there's a better way.  My
> >>>>>>>>>> thought is:
> >>>>>>>>>>
> >>>>>>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
> >>>>>>>>>>
> >>>>>>>>>> ...a -> b -> c -> merge commit ->
> >>>>>>>>>> ...x-> q -> z ->   ---^
> >>>>>>>>>>
> >>>>>>>>>> to just:
> >>>>>>>>>>
> >>>>>>>>>> ...a -> b -> c -> merge commit ->
> >>>>>>>>>>
> >>>>>>>>>> If we do that, maybe q and z are good commits we want, but x and
> >>>>>>>>>> everything before is not. Here we were then talking about cherry
> >>>>>>>>>> picking.
> >>>>>>>>>>
> >>>>>>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
> >>>>>>>>>> interesting commit.  So for the above, maybe we edit q, change its
> >>>>>>>>>> parent to c, then hopefully all is right, something like:
> >>>>>>>>>>
> >>>>>>>>>> ...a -> b -> c ------->  merge commit ->
> >>>>>>>>>>            \--> q -> z ->   ---^
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Regarding the first path, I just tried running the filter branch with:
> >>>>>>>>>>
> >>>>>>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
> >>>>>>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
> >>>>>>>>>> seconds passed, remaining 0 predicted)
> >>>>>>>>>> Ref 'refs/heads/develop' was rewritten
> >>>>>>>>>>
> >>>>>>>>>> and got the above. I could then delete the entries in
> >>>>>>>>>> .git/refs/replace and still have 15K entries.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I think we should try #2 next, as in my head it's sort of what we're
> >>>>>>>>>> wanting in the end and seems more correct than trying to cherry-pick.
> >>>>>>>>>> (Could use the same replace --edit command I think.) I've got a fair
> >>>>>>>>>> amount of other work to do now, but will try to take a look later in
> >>>>>>>>>> the day if you haven't gotten to it first.
> >>>>>>>>>>
> >>>>>>>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I did three modifications:
> >>>>>>>>>>>
> >>>>>>>>>>> 1) git replace --edit 4a7ea2c7e6
> >>>>>>>>>>>
> >>>>>>>>>>> removing cc84b961d
> >>>>>>>>>>>
> >>>>>>>>>>> 2) git replace --edit 7894927615
> >>>>>>>>>>>
> >>>>>>>>>>> removing e4ca0b12a
> >>>>>>>>>>>
> >>>>>>>>>>> 3) git replace —edit 2b6c5bffdd46e07
> >>>>>>>>>>>
> >>>>>>>>>>> removing 00eb43efb
> >>>>>>>>>>>
> >>>>>>>>>>> and ended up with 15k commits in HEAD.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> And yes I saw that paragraph at the time and it horrified me.
> >>>>>>>>>>>
> >>>>>>>>>>> ========================
> >>>>>>>>>>> Prof. Victor Lazzarini
> >>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>>>>>> Maynooth University,
> >>>>>>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>>>>>> Tel: 00 353 7086936
> >>>>>>>>>>> Fax: 00 353 1 7086952
> >>>>>>>>>>>
> >>>>>>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>>>>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
> >>>>>>>>>>>> other commits too?  I'm not sure what I might be doing differently
> >>>>>>>>>>>> here locally.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I see that that commit was a merge from a pull request related to
> >>>>>>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
> >>>>>>>>>>>> were a few other pull requests.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Side note, I saw this on the github page for removing sensitive data
> >>>>>>>>>>>> from a git repository
> >>>>>>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
> >>>>>>>>>>>> I think we used this when we did the VST-related change):
> >>>>>>>>>>>>
> >>>>>>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
> >>>>>>>>>>>> created off of your old (tainted) repository history. One merge commit
> >>>>>>>>>>>> could reintroduce some or all of the tainted history that you just
> >>>>>>>>>>>> went to the trouble of purging."
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Victor,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
> >>>>>>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
> >>>>>>>>>>>>> actually checked out a fresh copy of Csound before learning one could
> >>>>>>>>>>>>> just delete the entries in that folder.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> and in the first reply it says you can make the change permanent using either:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
> >>>>>>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
> >>>>>>>>>>>>> to see if that hasn't been cleared up.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'll give that a try now here locally to see what happens and report
> >>>>>>>>>>>>> back momentarily.  After that, my thought for the commit history that
> >>>>>>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
> >>>>>>>>>>>>> to me is that, by removing commits from history, I would have expected
> >>>>>>>>>>>>> later commits to become something of a mess since things are diffs. I
> >>>>>>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
> >>>>>>>>>>>>> that will get removed. Or perhaps the issues will arise on
> >>>>>>>>>>>>> filter-branch.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Will test now and reply in a moment.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>> steven
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Steven
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
> >>>>>>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
> >>>>>>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
> >>>>>>>>>>>>>> I checked the parents
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
> >>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
> >>>>>>>>>>>>>> removing it with git replace. Now I have
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> git rev-list --count HEAD
> >>>>>>>>>>>>>> 15049
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So I think we found it. Two questions before we move to fix this:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
> >>>>>>>>>>>>>> maybe we need to cherry pick?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
> >>>>>>>>>>>>>> refs get removed, we get the whole messed history back.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> best
> >>>>>>>>>>>>>> ========================
> >>>>>>>>>>>>>> Prof. Victor Lazzarini
> >>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
> >>>>>>>>>>>>>> Maynooth University,
> >>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
> >>>>>>>>>>>>>> Tel: 00 353 7086936
> >>>>>>>>>>>>>> Fax: 00 353 1 7086952
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --oneline --ancestry-path 652633..
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>

Ok. I might be able to do this tonight after 9pm. I will report back.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 7 Sep 2018, at 16:37, Steven Yi  wrote:
> 
> I think we're on the same page and will get the same results either
> way. I think we should go for it now and move on to the Wiki and
> announcements after that.
>> On Thu, Sep 6, 2018 at 9:57 AM Victor Lazzarini  wrote:
>> 
>> yes, but I would suggest a slight simplification
>> 
>> 1) pull latest from develop
>> 2) create a branch locally to old-develop
>> 3) apply process to develop
>> 4) push it
>> 5) push old-develop to origin
>> 
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 6 Sep 2018, at 14:52, Steven Yi  wrote:
>>> 
>>> That makes sense to not bother cherry-picking and redo the process
>>> from latest develop to make life simpler.
>>> 
>>> How about in a local new clone:
>>> 
>>> 1. reapply process in new local dev2
>>> 2. keep copy of local develop
>>> 3. delete origin/develop
>>> 4. push dev2 to origin/develop
>>> 5. push develop to origin/old-develop-bad
>>> 
>>> ?
>>> 
>>>> On Thu, Sep 6, 2018 at 8:49 AM Victor Lazzarini  wrote:
>>>> 
>>>> If that is the case, could we not just apply my method to develop? We could create a branch for safety and then go for it?
>>>> 
>>>> That is, instead of cherry picking.
>>>> 
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>> On 6 Sep 2018, at 13:45, Steven Yi  wrote:
>>>>> 
>>>>> I didn't try reproducing just looked at the dev2 branch (looks like
>>>>> both dev2 and develop2 are on github now).  I did:
>>>>> 
>>>>> git diff dev2..develop
>>>>> 
>>>>> and the only file diffs it showed were for John's most recent commit.
>>>>> I think if we cherry pick that, we're good.
>>>>> 
>>>>> It'd be good to get additional double-check since this is a big change
>>>>> in a way and we're going to have to commit to it.  Felipe or Stephen,
>>>>> could you perhaps take a look?
>>>>> 
>>>>> I think next steps would be:
>>>>> 
>>>>> 1. Cherry-pick John's last commit from develop
>>>>> 2. Merge master into dev2 (so we can clean merge to master when do
>>>>> release, and there's a merge conflict to fix if you try it locally)
>>>>> 3. Delete develop from remote
>>>>> 4. Re-push develop from local to remote as old-develop (let's keep it
>>>>> around for short term)
>>>>> 5. Push dev2 to remote as develop
>>>>> 
>>>>> For everyone in the ecosystem, I'm not quite sure what the exact steps
>>>>> are. We need to account for:
>>>>> 
>>>>> 1. Developers and people with local git repos: Perhaps promote
>>>>> deleting local repository and re-clone?
>>>>> 2. For github forks: not sure here? Some sort of rebase operation?
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>> 
>>>>>>> On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> Ops, only realised the dev2 branch was already there. I will make it develop2
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>> 
>>>>>>>> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
>>>>>>>> 
>>>>>>>> 1) For the first two commits, I just replaced the merge as before
>>>>>>>> 
>>>>>>>> $ git replace --edit 4a7ea2c7e6
>>>>>>>> removing cc84b961d
>>>>>>>> $ git replace --edit 7894927615
>>>>>>>> removing e4ca0b12a
>>>>>>>> 
>>>>>>>> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
>>>>>>>> and found two commits back in the history that there was a duplicate
>>>>>>>> merge.
>>>>>>>> 
>>>>>>>> The child of one of this duplicates is (two down from 2b6c5bffd)
>>>>>>>> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
>>>>>>>> 
>>>>>>>> the parent, one of the duplicate merges, is
>>>>>>>> 
>>>>>>>> 394c43edd0dd68f992647f51b00f78c33564987a
>>>>>>>> 
>>>>>>>> and the correct merge in the history was
>>>>>>>> 
>>>>>>>> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
>>>>>>>> 
>>>>>>>> So I edited
>>>>>>>> $ git replace --edit 4e4721c9f85329
>>>>>>>> and replaced the first (39…) by the second (83...)
>>>>>>>> 
>>>>>>>> Now I have 15051 commits. I think we can apply
>>>>>>>> filter-branch to this and it will fix the problem. You can
>>>>>>>> re-trace my steps above and verify it.
>>>>>>>> 
>>>>>>>> I have pushed a dev2 branch to which I applied
>>>>>>>> the filter so you can have a look at.
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>> 
>>>>>>>>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
>>>>>>>>> 
>>>>>>>>> Yes, please do give it a go if you have the time. (I'm a bit
>>>>>>>>> intermittent to get to most anything outside of work at the moment.)
>>>>>>>>>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>>>>>>>>>> 
>>>>>>>>>> Btw, let me know if you want help with this.
>>>>>>>>>> ========================
>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>> Maynooth University,
>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>> 
>>>>>>>>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>>>>>>>>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>>>>>>>>>>> commits we want to keep.
>>>>>>>>>>> 
>>>>>>>>>>> In any case,  if 1) works and we can always cherry pick.
>>>>>>>>>>> 
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>> 
>>>>>>>>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>>>>>>>>>>>> filter-branch now, but I'm wondering if there's a better way.  My
>>>>>>>>>>>> thought is:
>>>>>>>>>>>> 
>>>>>>>>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>>>>>>>>>>>> 
>>>>>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>>>>>> ...x-> q -> z ->   ---^
>>>>>>>>>>>> 
>>>>>>>>>>>> to just:
>>>>>>>>>>>> 
>>>>>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>>>>>> 
>>>>>>>>>>>> If we do that, maybe q and z are good commits we want, but x and
>>>>>>>>>>>> everything before is not. Here we were then talking about cherry
>>>>>>>>>>>> picking.
>>>>>>>>>>>> 
>>>>>>>>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>>>>>>>>>>>> interesting commit.  So for the above, maybe we edit q, change its
>>>>>>>>>>>> parent to c, then hopefully all is right, something like:
>>>>>>>>>>>> 
>>>>>>>>>>>> ...a -> b -> c ------->  merge commit ->
>>>>>>>>>>>>           \--> q -> z ->   ---^
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Regarding the first path, I just tried running the filter branch with:
>>>>>>>>>>>> 
>>>>>>>>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>>>>>>>>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>>>>>>>>>>>> seconds passed, remaining 0 predicted)
>>>>>>>>>>>> Ref 'refs/heads/develop' was rewritten
>>>>>>>>>>>> 
>>>>>>>>>>>> and got the above. I could then delete the entries in
>>>>>>>>>>>> .git/refs/replace and still have 15K entries.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I think we should try #2 next, as in my head it's sort of what we're
>>>>>>>>>>>> wanting in the end and seems more correct than trying to cherry-pick.
>>>>>>>>>>>> (Could use the same replace --edit command I think.) I've got a fair
>>>>>>>>>>>> amount of other work to do now, but will try to take a look later in
>>>>>>>>>>>> the day if you haven't gotten to it first.
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I did three modifications:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 1) git replace --edit 4a7ea2c7e6
>>>>>>>>>>>>> 
>>>>>>>>>>>>> removing cc84b961d
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2) git replace --edit 7894927615
>>>>>>>>>>>>> 
>>>>>>>>>>>>> removing e4ca0b12a
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 3) git replace —edit 2b6c5bffdd46e07
>>>>>>>>>>>>> 
>>>>>>>>>>>>> removing 00eb43efb
>>>>>>>>>>>>> 
>>>>>>>>>>>>> and ended up with 15k commits in HEAD.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> And yes I saw that paragraph at the time and it horrified me.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ========================
>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>>>>>>>>>>>> other commits too?  I'm not sure what I might be doing differently
>>>>>>>>>>>>>> here locally.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I see that that commit was a merge from a pull request related to
>>>>>>>>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>>>>>>>>>>>> were a few other pull requests.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Side note, I saw this on the github page for removing sensitive data
>>>>>>>>>>>>>> from a git repository
>>>>>>>>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>>>>>>>>>>>> I think we used this when we did the VST-related change):
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>>>>>>>>>>>> created off of your old (tainted) repository history. One merge commit
>>>>>>>>>>>>>> could reintroduce some or all of the tainted history that you just
>>>>>>>>>>>>>> went to the trouble of purging."
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi Victor,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>>>>>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>>>>>>>>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>>>>>>>>>>>> just delete the entries in that folder.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> and in the first reply it says you can make the change permanent using either:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>>>>>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>>>>>>>>>>>> to see if that hasn't been cleared up.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'll give that a try now here locally to see what happens and report
>>>>>>>>>>>>>>> back momentarily.  After that, my thought for the commit history that
>>>>>>>>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>>>>>>>>>>>> to me is that, by removing commits from history, I would have expected
>>>>>>>>>>>>>>> later commits to become something of a mess since things are diffs. I
>>>>>>>>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>>>>>>>>>>>> that will get removed. Or perhaps the issues will arise on
>>>>>>>>>>>>>>> filter-branch.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Will test now and reply in a moment.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>> steven
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi Steven
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>>>>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>>>>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>>>>>>>>>>>> I checked the parents
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>>>>>>>>>>>> removing it with git replace. Now I have
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> git rev-list --count HEAD
>>>>>>>>>>>>>>>> 15049
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>>>>>>>>>>>> maybe we need to cherry pick?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>>>>>>>>>>>> refs get removed, we get the whole messed history back.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> --oneline --ancestry-path 652633..
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>

Ok, I’ve hit a snag. I’ve pulled to get the latest commits,  then pushed the old-develop branch. and made the changes locally to 
the develop branch. When I tried to push, it would not do it, saying that the tip of 
the branch was behind. On a separate experimental clone, I repeated the operation
and then pulled from develop. Of course, it pulled all of the tainted commits back into
my local. 

So I think we’ll need to do a new branch, then torch develop, as suggested.
I’ll try that now.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 7 Sep 2018, at 17:06, Victor Lazzarini  wrote:
> 
> Ok. I might be able to do this tonight after 9pm. I will report back.
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
>> On 7 Sep 2018, at 16:37, Steven Yi  wrote:
>> 
>> I think we're on the same page and will get the same results either
>> way. I think we should go for it now and move on to the Wiki and
>> announcements after that.
>>> On Thu, Sep 6, 2018 at 9:57 AM Victor Lazzarini  wrote:
>>> 
>>> yes, but I would suggest a slight simplification
>>> 
>>> 1) pull latest from develop
>>> 2) create a branch locally to old-develop
>>> 3) apply process to develop
>>> 4) push it
>>> 5) push old-develop to origin
>>> 
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 6 Sep 2018, at 14:52, Steven Yi  wrote:
>>>> 
>>>> That makes sense to not bother cherry-picking and redo the process
>>>> from latest develop to make life simpler.
>>>> 
>>>> How about in a local new clone:
>>>> 
>>>> 1. reapply process in new local dev2
>>>> 2. keep copy of local develop
>>>> 3. delete origin/develop
>>>> 4. push dev2 to origin/develop
>>>> 5. push develop to origin/old-develop-bad
>>>> 
>>>> ?
>>>> 
>>>>> On Thu, Sep 6, 2018 at 8:49 AM Victor Lazzarini  wrote:
>>>>> 
>>>>> If that is the case, could we not just apply my method to develop? We could create a branch for safety and then go for it?
>>>>> 
>>>>> That is, instead of cherry picking.
>>>>> 
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 6 Sep 2018, at 13:45, Steven Yi  wrote:
>>>>>> 
>>>>>> I didn't try reproducing just looked at the dev2 branch (looks like
>>>>>> both dev2 and develop2 are on github now).  I did:
>>>>>> 
>>>>>> git diff dev2..develop
>>>>>> 
>>>>>> and the only file diffs it showed were for John's most recent commit.
>>>>>> I think if we cherry pick that, we're good.
>>>>>> 
>>>>>> It'd be good to get additional double-check since this is a big change
>>>>>> in a way and we're going to have to commit to it.  Felipe or Stephen,
>>>>>> could you perhaps take a look?
>>>>>> 
>>>>>> I think next steps would be:
>>>>>> 
>>>>>> 1. Cherry-pick John's last commit from develop
>>>>>> 2. Merge master into dev2 (so we can clean merge to master when do
>>>>>> release, and there's a merge conflict to fix if you try it locally)
>>>>>> 3. Delete develop from remote
>>>>>> 4. Re-push develop from local to remote as old-develop (let's keep it
>>>>>> around for short term)
>>>>>> 5. Push dev2 to remote as develop
>>>>>> 
>>>>>> For everyone in the ecosystem, I'm not quite sure what the exact steps
>>>>>> are. We need to account for:
>>>>>> 
>>>>>> 1. Developers and people with local git repos: Perhaps promote
>>>>>> deleting local repository and re-clone?
>>>>>> 2. For github forks: not sure here? Some sort of rebase operation?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Thu, Sep 6, 2018 at 4:56 AM Victor Lazzarini  wrote:
>>>>>>> 
>>>>>>> Actually, no, there wasn’t a dev2, I just got confused by the last commit message...
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>> 
>>>>>>>> On 6 Sep 2018, at 09:51, Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> Ops, only realised the dev2 branch was already there. I will make it develop2
>>>>>>>> ========================
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>> 
>>>>>>>>> On 6 Sep 2018, at 09:43, Victor Lazzarini  wrote:
>>>>>>>>> 
>>>>>>>>> Ok, pursuing your second idea, I’ve got some better results. Here’s what I did
>>>>>>>>> 
>>>>>>>>> 1) For the first two commits, I just replaced the merge as before
>>>>>>>>> 
>>>>>>>>> $ git replace --edit 4a7ea2c7e6
>>>>>>>>> removing cc84b961d
>>>>>>>>> $ git replace --edit 7894927615
>>>>>>>>> removing e4ca0b12a
>>>>>>>>> 
>>>>>>>>> 2) For the third one, I examined the tree starting from 2b6c5bffdd46e07
>>>>>>>>> and found two commits back in the history that there was a duplicate
>>>>>>>>> merge.
>>>>>>>>> 
>>>>>>>>> The child of one of this duplicates is (two down from 2b6c5bffd)
>>>>>>>>> 4e4721c9f85329c490b3114d3b8c0816ea90e35c
>>>>>>>>> 
>>>>>>>>> the parent, one of the duplicate merges, is
>>>>>>>>> 
>>>>>>>>> 394c43edd0dd68f992647f51b00f78c33564987a
>>>>>>>>> 
>>>>>>>>> and the correct merge in the history was
>>>>>>>>> 
>>>>>>>>> 8372f32b8aa6d2d90da8900ddadeea8f157df1a5
>>>>>>>>> 
>>>>>>>>> So I edited
>>>>>>>>> $ git replace --edit 4e4721c9f85329
>>>>>>>>> and replaced the first (39…) by the second (83...)
>>>>>>>>> 
>>>>>>>>> Now I have 15051 commits. I think we can apply
>>>>>>>>> filter-branch to this and it will fix the problem. You can
>>>>>>>>> re-trace my steps above and verify it.
>>>>>>>>> 
>>>>>>>>> I have pushed a dev2 branch to which I applied
>>>>>>>>> the filter so you can have a look at.
>>>>>>>>> ========================
>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>> 
>>>>>>>>>> On 5 Sep 2018, at 14:17, Steven Yi  wrote:
>>>>>>>>>> 
>>>>>>>>>> Yes, please do give it a go if you have the time. (I'm a bit
>>>>>>>>>> intermittent to get to most anything outside of work at the moment.)
>>>>>>>>>>> On Wed, Sep 5, 2018 at 7:12 AM Victor Lazzarini  wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Btw, let me know if you want help with this.
>>>>>>>>>>> ========================
>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>> 
>>>>>>>>>>>> On 4 Sep 2018, at 12:50, Victor Lazzarini  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks, I think for the first two commits to be fixed, we can safely do 1) and there is no
>>>>>>>>>>>> cherry picking involved. For the third one, we can attempt 2) as there is a couple of
>>>>>>>>>>>> commits we want to keep.
>>>>>>>>>>>> 
>>>>>>>>>>>> In any case,  if 1) works and we can always cherry pick.
>>>>>>>>>>>> 
>>>>>>>>>>>> ========================
>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 4 Sep 2018, at 12:40, Steven Yi  wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Ah thanks, the third one there did it for me here. I'm trying out the
>>>>>>>>>>>>> filter-branch now, but I'm wondering if there's a better way.  My
>>>>>>>>>>>>> thought is:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 1. If we remove the parent, we lose the commits, somewhat going from:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>>>>>>> ...x-> q -> z ->   ---^
>>>>>>>>>>>>> 
>>>>>>>>>>>>> to just:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ...a -> b -> c -> merge commit ->
>>>>>>>>>>>>> 
>>>>>>>>>>>>> If we do that, maybe q and z are good commits we want, but x and
>>>>>>>>>>>>> everything before is not. Here we were then talking about cherry
>>>>>>>>>>>>> picking.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2. Maybe instead of editing the merge commit, we modify the earliest
>>>>>>>>>>>>> interesting commit.  So for the above, maybe we edit q, change its
>>>>>>>>>>>>> parent to c, then hopefully all is right, something like:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ...a -> b -> c ------->  merge commit ->
>>>>>>>>>>>>>          \--> q -> z ->   ---^
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regarding the first path, I just tried running the filter branch with:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> $ git filter-branch --tag-name-filter cat -- 652633..head
>>>>>>>>>>>>> Rewrite 654c6ac5cdef7d57595472bd430bb3089a6c3f4c (242/242) (107
>>>>>>>>>>>>> seconds passed, remaining 0 predicted)
>>>>>>>>>>>>> Ref 'refs/heads/develop' was rewritten
>>>>>>>>>>>>> 
>>>>>>>>>>>>> and got the above. I could then delete the entries in
>>>>>>>>>>>>> .git/refs/replace and still have 15K entries.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think we should try #2 next, as in my head it's sort of what we're
>>>>>>>>>>>>> wanting in the end and seems more correct than trying to cherry-pick.
>>>>>>>>>>>>> (Could use the same replace --edit command I think.) I've got a fair
>>>>>>>>>>>>> amount of other work to do now, but will try to take a look later in
>>>>>>>>>>>>> the day if you haven't gotten to it first.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 7:24 AM Victor Lazzarini  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I did three modifications:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1) git replace --edit 4a7ea2c7e6
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> removing cc84b961d
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 2) git replace --edit 7894927615
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> removing e4ca0b12a
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 3) git replace —edit 2b6c5bffdd46e07
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> removing 00eb43efb
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and ended up with 15k commits in HEAD.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> And yes I saw that paragraph at the time and it horrified me.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 4 Sep 2018, at 12:12, Steven Yi  wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I tried editing the commit 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>>>>>>> but still had 29931 commits afterwards. Victor: did you modify any
>>>>>>>>>>>>>>> other commits too?  I'm not sure what I might be doing differently
>>>>>>>>>>>>>>> here locally.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I see that that commit was a merge from a pull request related to
>>>>>>>>>>>>>>> fixes for WebAudio Csound. It looks like since the VST cleaning, there
>>>>>>>>>>>>>>> were a few other pull requests.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Side note, I saw this on the github page for removing sensitive data
>>>>>>>>>>>>>>> from a git repository
>>>>>>>>>>>>>>> (https://help.github.com/articles/removing-sensitive-data-from-a-repository/,
>>>>>>>>>>>>>>> I think we used this when we did the VST-related change):
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> "Tell your collaborators to rebase, not merge, any branches they
>>>>>>>>>>>>>>> created off of your old (tainted) repository history. One merge commit
>>>>>>>>>>>>>>> could reintroduce some or all of the tainted history that you just
>>>>>>>>>>>>>>> went to the trouble of purging."
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 6:57 AM Steven Yi  wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi Victor,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks for looking into this! And sorry I should have mentioned the
>>>>>>>>>>>>>>>> .git/refs/replace thing; I ran into the same thing yesterday and
>>>>>>>>>>>>>>>> actually checked out a fresh copy of Csound before learning one could
>>>>>>>>>>>>>>>> just delete the entries in that folder.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I was proceeding from the StackOverflow link Felipe posted:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> https://stackoverflow.com/questions/14244888/remove-spurious-commit-parent-pointer
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> and in the first reply it says you can make the change permanent using either:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> git filter-branch --tag-name-filter cat -- ..head
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> to only rewrite a range of commits, which seems appropriate.  I
>>>>>>>>>>>>>>>> suppose one could give it a try and check .git/refs/replace afterwards
>>>>>>>>>>>>>>>> to see if that hasn't been cleared up.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I'll give that a try now here locally to see what happens and report
>>>>>>>>>>>>>>>> back momentarily.  After that, my thought for the commit history that
>>>>>>>>>>>>>>>> was removed was to cherry-pick. One thing that's sort of interesting
>>>>>>>>>>>>>>>> to me is that, by removing commits from history, I would have expected
>>>>>>>>>>>>>>>> later commits to become something of a mess since things are diffs. I
>>>>>>>>>>>>>>>> suppose we're either lucky in that later commits don't touch the ones
>>>>>>>>>>>>>>>> that will get removed. Or perhaps the issues will arise on
>>>>>>>>>>>>>>>> filter-branch.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Will test now and reply in a moment.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>> steven
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Tue, Sep 4, 2018 at 5:53 AM Victor Lazzarini  wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hi Steven
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I think I’ve found the issue. Reviewing your steps, I realised it was all OK and I thought the steps
>>>>>>>>>>>>>>>>> were correct, so I suspected another commit. By checking the number of commits from that
>>>>>>>>>>>>>>>>> last one you replaced onwards, I noticed that they were all 14k until
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 2b6c5bffdd46e07dd36b44a04ce8cc19516520ef
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> which was a merge request commit. That seemed to have brought in the duplicate history.
>>>>>>>>>>>>>>>>> I checked the parents
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..00eb43efb
>>>>>>>>>>>>>>>>> git log --oneline --ancestry-path 652633..1c7f7c7a0
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> and found that the first one had no shared commits and proceeded as you did,
>>>>>>>>>>>>>>>>> removing it with git replace. Now I have
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> git rev-list --count HEAD
>>>>>>>>>>>>>>>>> 15049
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> So I think we found it. Two questions before we move to fix this:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 1) It is a merge request. So we’ll loose the changes if we just replace it,
>>>>>>>>>>>>>>>>> maybe we need to cherry pick?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 2) Is git replace a permanent solution? It seems to be workable, but if the
>>>>>>>>>>>>>>>>> refs get removed, we get the whole messed history back.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> best
>>>>>>>>>>>>>>>>> ========================
>>>>>>>>>>>>>>>>> Prof. Victor Lazzarini
>>>>>>>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>>>>>>>>>>>> Maynooth University,
>>>>>>>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 3 Sep 2018, at 23:33, Steven Yi  wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --oneline --ancestry-path 652633..
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>