for latex math

[aszasz]

I want to be sure that this passes (because of #24) before inserting chapters 6, 7 and 24.

[aszasz]

Hi there bosses... GitHub tells me that (and give me powers and a button) to Delete branch... I would do it, but want to be sure it is appropriate.

So you know: I will create new pull requests for chapters 6,7 and 24: they will be like this:

• locally branch from development with latest updates (each chapter)
• locally checkout files (only the appropriated ones, that nobody else touched) from my old branches
• I really don't mind loosing the commit history for Chapter Six (which just says "add a section", "add another section", "save as is" "add another section")... for the other two chapters, I will keep those records (and hopefuly finish them soon), unless you tell me otherwise.

[jonasmalacofilho]

I guess it depends on why the new pull requests are necessary... Can you elaborate?

Either way, it's usually interesting to keep most of the available history; even seemingly useless commits can help a debugging session in the future. At the same time, it's regular practice to rewrite the history or commits in a reasonable sequence or organized (and linearized) changes, at least if the contributor knows how (or in high profile repositories where the maintainers demand it).

For now (and if you have the time), can I recommend that you make a little experiment with the interactive rebase (git rebase --interactive)? Just make sure you have a backup of the branch you're rewriting (git branch <backup-name>).

Or, if what you need is really much simpler, how about a regular git rebase or, even, a git merge --squash?

[lehonma]

I redid the old pull requests because I was working on an older working tree (with *.emfs on Chapter 5, for example), from before your filter branch. I tried to rebase but my working tree was odd (to say the least), so I had to clone the development and cherry-pick my stuff.

This could be Arthur's issue, I can investigate here.

[jonasmalacofilho]

Oh, I see. (so it's just chapters 6 and 7 then?)

I think a git merge --squash (or, in fact, the GitHub web equivalent) is the easiest and cleanest option. This way there are no pull requests left hanging and there's minimal work involved (two clicks).

The only downside is this does indeed loose git history (although github still keeps it, accessible from the pull request page). But that's fine by me, you and @aszasz are right that history in this case is not that important, and I can confirm that using rebase to cleanup the emf/lfs garbage (without loosing the history) is really very troublesome.

[jonasmalacofilho]

Oh, just make sure that all things in LFS are indeed in LFS before merging them into the development branch. Maybe a temporary branch (on the main repository) in still necessary, just so that our LFS checks (on TravisCI) can run...

---

There's a change that for new branches the checks will run for the entire history... in that case, some old "garbage" will be reported either way, so a careful analysis of that log might be necessary... : /

[jonasmalacofilho]

Hm... One last thought: due to the need to check that no more rogue LFS objects are introduced, maybe the following is better:

# on the pull request branch
git branch <backup-name>
git fetch <upstream>
# still on the pull request branch
git reset --hard <upstream>/development
git merge --squash <backup-name>
git push --force

Basically:

• backup
• make the pull request branch be the squashed merge of the pull request contents (the backup) on top of the current development head
• force push

[lehonma]

I checked Travis' logs... and he had problems with EMFs on Chapter 5 and 6 plus some JPEGs on Chapter 32

[jonasmalacofilho]

I'm checking the branch, just a sec.

[jonasmalacofilho]

I'll leave a specific comment on #27

[aszasz]

Got it all, thanks: if time permits I will preserve history for the exercise. The thing about the squash (yeap, I've seen the button with the alternative when I merged this branch into development) is that I am VERY afraid of unwillingly taint the development again, and add unecessary (large) files to every cloning.

Last thing (which was the question) ... should I delete this branch?

[jonasmalacofilho]

Sure, it's fine. The commits and conversation are preserved, so the original branch on your fork is not necessary anymore (and keeping it can unnecessarily pollute your fork).