Salvage the original history of the files

[csillag]

As explained by @nickstenning:

I'm concerned that we've squashed the history of the range module in the new git repo.
If at all possible, I'd like to see the git history of the range module preserved.
You can do this with git-filter-branch. Here's one possible approach: https://gist.github.com/ssp/1663093.

[tilgovi]

I just pushed a branch, "salvage".

Here's what I did:

$ git filter-branch -f --prune-empty --index-filter 'git rm -r --cached --ignore-unmatch $(git ls-files | grep -v "xpath\|range")'
$ git filter-branch -f --prune-empty --index-filter 'git rm -r --cached --ignore-unmatch src/plugin test/spec/plugin lib'
$ git checkout -b temp
$ git checkout master
$ git rebase temp

Then I cleaned up the duplicate "Initial commit" changes with an interactive rebase to squash them and reword it as "Packaging for separated xpath-range project".

How this worked:

• Rewrite history filtering out any files that don't match "xpath" or "range"
• Rewrite again explicitly removing lib/ and plugin/ directories. The lib directory had lib/vendor/xpath.js and the plugin directories had legacyrange.coffee which both matched the regex.
• Give this branch a name, "temp"
• Stack master on top of this
• Clean up via squashing as normal

Then I pushed that to the new branch.

If this looks good, just delete the existing master and replace it with this branch.

[tilgovi]

@gergely-ujvari @rawkstar77 I think you both said you wanted to see these commands, too.

[nickstenning]

I've only had a very quick look, but looks good to me.

[nickstenning]

Actually, tiny thing -- it might make sense to start the history at 0715866, and rebase out the commits before that.

[csillag]

If this looks good, just delete the existing master and replace it with this branch.

Do we really have to keep comments that have statistics like this:
0 changed files with 0 additions and 0 deletions.
?

[nickstenning]

Do we really have to keep comments that have statistics like this:
0 changed files with 0 additions and 0 deletions.

No, but IIRC this is a bug (oversight) in filter-branch. --prune-empty removes empty commits, but not if a commit has multiple parents. You'll note that the only empty commits that remain (from a quick glance...) are merges.

I think I've solved this in the past by using --index-filter first to move all the files I'm interested in into their own subdirectory, and then using --subdirectory-filter to pull the history of that subdir on its own.

[tilgovi]

I didn't do the subdirectory filter because the structures matched.

I've no problem with the empty merges.
On Jun 24, 2014 2:30 PM, "Nick Stenning" notifications@github.com wrote:

Do we really have to keep comments that have statistics like this:
0 changed files with 0 additions and 0 deletions.

No, but iirc this is a bug (oversight). --prune-empty removes empty
commits, but not if a commit has multiple parents. You'll note that the
only empty commits that remain (from a quick glance...) are merges.

I think I've solved this in the past by using --index-filter first to
move all the files i'm interested in into their own subdirectory, and then
using --subdirectory-filter to pull the history of that subdir on its own.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[csillag]

On 2014-06-24 23:55, Randall Leeds wrote:

I didn't do the subdirectory filter because the structures matched.

I've no problem with the empty merges.

Maybe I'll just rebase those empty merge commits out manually.

[tilgovi]

Careful.... I'm not sure removing the merge commits is easy.

Or at least, it will lose the merge history. Which might be okay.

But I'd ask whether it's worth putting any time into it.

Preserving the history is about attribution to me. I'm not concerned with
obsessive cleanliness in this scenario.
On Jun 24, 2014 3:23 PM, "Kristof Csillag" notifications@github.com wrote:

On 2014-06-24 23:55, Randall Leeds wrote:

I didn't do the subdirectory filter because the structures matched.

I've no problem with the empty merges.

Maybe I'll just rebase those empty merge commits out manually.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[csillag]

On 2014-06-25 00:30, Randall Leeds wrote:

Careful.... I'm not sure removing the merge commits is easy.

Or at least, it will lose the merge history. Which might be okay.

But I'd ask whether it's worth putting any time into it.

Preserving the history is about attribution to me. I'm not concerned with
obsessive cleanliness in this scenario.

Fine. Then it stays as it is.

(Except that I'll squash the npm packaging-related experiments into one
step.)

[csillag]

All done, so I am closing this one.