LTO config and workarounds touchup and two new workarounds

[elsandosgrande]

1. Regarding the description of c9bb8e4, I was very sleepy when I wrote that, so my logic was flawed (I realize that using ${LTO} would not prevent a setup using -fwhole-program from working) and, ironically, that was one of the only workarounds not embedding a string within a string.
2. I know that this is a lot of changes at once, but by the time I realized that it is too much, there was no going back, as stashing commits is not a thing (or at least didn't work for me if it is a thing).

[wolfwood]

@elsandosgrande you can make feature branches based on origin/master and then git cherry-pick commits into the feature branches and make individual Pull Requests from each branch.

[elsandosgrande]

@wolfwood Tried before, but never got it to work properly. Also, do you know how to get rid of commits which were already accepted in previous pull requests (anything before c9bb8e4)? I have never had this issue in the Olive repository.

[wolfwood]

merge master into this branch. or to really clean up, rebase this branch onto master, which will let you squash commits, etc. but since it edits history you'll need to force push.

[elsandosgrande]

@wolfwood
This is master though (my master, but still...). I tried to rebase, but I just got a lot of conflicts, mostly due to deleted files. I have tried git rebase upstream/master --rebase-merges, but git status reports nothing.

sandy@sandys-pavilion:/opt/gentooLTO$ git rebase upstream/master --rebase-merges
Successfully rebased and updated refs/heads/master.
sandy@sandys-pavilion:/opt/gentooLTO$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
sandy@sandys-pavilion:/opt/gentooLTO$ git push
QSocketNotifier: Can only be used with threads started with QThread
QFileSystemWatcher::removePaths: list is empty
QFileSystemWatcher::removePaths: list is empty
QSocketNotifier: Can only be used with threads started with QThread
QFileSystemWatcher::removePaths: list is empty
QFileSystemWatcher::removePaths: list is empty
Everything up-to-date
sandy@sandys-pavilion:/opt/gentooLTO$ git push --force
QSocketNotifier: Can only be used with threads started with QThread
QFileSystemWatcher::removePaths: list is empty
QFileSystemWatcher::removePaths: list is empty
QSocketNotifier: Can only be used with threads started with QThread
QFileSystemWatcher::removePaths: list is empty
QFileSystemWatcher::removePaths: list is empty
Everything up-to-date

Edit

Just to clarify, it's not like there are just one or two conflicts, but there are conflicts with roughly 80% of the commits.

Edit

I realize now that I should have used a separate branch (that's why I couldn't get cherry picking to work...). Oh well, you live and you learn.

Prays that Shane does not smite him

[InBetweenNames]

I largely agree with these changes -- there's no real need to have environment variables for single flag workarounds like -fno-common. The only thing is renaming FLTO to LTO could break some peoples setups... but that's fixable with a news bulletin.

[elsandosgrande]

I was actually thinking of mentioning the possibility of a news item.

Hm... @InBetweenNames, I have an idea. Give me a minute.

[elsandosgrande]

There, that should cover it.

Edit

Also, @InBetweenNames, do you have an idea as to how to prevent commits that were already merged previously from appearing in future pull requests? You may refer to the conversation between me and wolfwood above to see what I have already (what did not work when I tried that).

[elsandosgrande]

elsandosgrande authored and InBetweenNames committed on Jul 4, 2019

Hm... In Olive, it lists my commits separately. Then again, Matthew set a "company" up on GitHub for Olive, while this is merely a personal repository. @wolfwood, regarding our earlier conversation, do you know if it is possible to replicate the behavior in another person's repository? I am not sure how to even formulate a search term for this...

Edit

By "separately", I meant that it says "elsandosgrande commited" after a pull request is merged.

[wolfwood]

@elsandosgrande

brute force approach:

git checkout -b stuff-sandy-likes master
git branch -D master
git checkout -b master origin/master
git checkout -b new-pull master
git cherry-pick commit ids you want from stuff-sandy-likes
git push new-pull origin/new-pull

[elsandosgrande]

All right, I will try making a new pull with that (I will keep this one opened just in case that the new one ends up being the exact same as this one). Shane, have mercy on me!

That still leaves me wondering "Why do commits from merged requests from people to this repository not appear as committed by them in the commit log, but merely as authored by them when they do not appear as such in Olive's repository?".

Edit

Well... @wolfwood, after copying and pasting your exact commands and finding the appropriate commit hashes, it seems that new-pull has all of my commits, without exception, and I am also greeted by this:

sandy@sandys-pavilion:/opt/gentooLTO$ git cherry-pick 3b82b9729eca27b6b17d73746c0aa6c4c5d261ec 54b9bbbe291e2c8e7c43d89c7c692897898a004e 7e2ad56e9afe75f31ea480ebcfce336db19facfc 477fbed042a96b98147a5675798fbdbb794f9627 66d7515da33663ab7f3e8f7e484fe1d78fab73a2 c9bb8e4648454aa4f340183c6713800759c18b2d
On branch new-pull
Cherry-pick currently in progress.

nothing to commit, working tree clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

and then use:

    git cherry-pick --continue

to resume cherry-picking the remaining commits.
If you wish to skip this commit, use:

    git cherry-pick --skip

sandy@sandys-pavilion:/opt/gentooLTO$ git log
commit 3b82b9729eca27b6b17d73746c0aa6c4c5d261ec (HEAD -> new-pull, origin/master, origin/HEAD, stuff-sandy-likes, master)
Author: elsandosgrande <sandyvujakovicj@outlook.com>
Date:   Thu Jan 9 11:23:28 2020 +0100

    Legacy variable support
    To think that **this** project would ever have the word "legacy" used anywhere...

commit 54b9bbbe291e2c8e7c43d89c7c692897898a004e
Author: elsandosgrande <sandyvujakovicj@outlook.com>
Date:   Tue Dec 10 15:38:58 2019 +0100

    Adding comments to relevant lines

***

...

... ... 😅

I will try this again when I translate the README, but this time before those commits are pushed to GitHub (of course, I will make a copy of my directory just in case).

[wolfwood]

ah, the problem is that you already pushed you local master to origin/master, which is your GitHub fork, not this repository.

git remote add this repository's url with a different name than origin, i call mine upstream.

remake your local master branch from upstream/master instead. (if you set it tracking, git pulls will automatically come from upstream rather than origin) then you should be good to make new-pull2 and cherry pick

or should be able to just rebase stuff-sandy-likes (or perhaps stuff-sandy-likes-copy) onto upstream/master

EDIT:
also looks like you have an incomplete cherry pick in progress, you should probably take the advice of the prompt to run git cherry-pick --skip to get back to normal

[elsandosgrande]

1. It is incomplete because there are no changes, that is the commit is "empty", at least as far as I can tell.
2. So... I just replace origin with upstream in the third command? All right (I already just deleted everything in the folder and cloned my fork).
3. Um... What about my other question (right above "Edit")?

[elsandosgrande]

So... @wolfwood, new-pull is only showing six commits in the difference now! I have already made it the new default branch and will proceed to delete master (rebasing just gives me errors, like before, new-pull already has the six new commits and I don't have the time to try to fight with git rebase for the exact commit history seeing as I failed last time) and subsequently rename new-pull to master, at which point I will make a new pull request.

@InBetweenNames, I have finally succeeded with the help of wolfwood!

[wolfwood]

@elsandosgrande you don't need to make a pull request from master. you can just push new-pull and make a PR from that, or any other branch.

regarding your other question, your author status maybe be because you have write access to Olive but not here, but i don't really know.

[elsandosgrande]

@wolfwood

1. I wanted to make new-pull into master, but rebasing did not work, so I had to make new-pull default, then delete master and then finally rename new-pull to master. My guess is that this pull request would not like that. And yes, I know that I can make a pull request from any branch, but new-pull already has all of the commits and is already clean, so...
2. I do not, I merely made pull requests like here, the only difference being that olive-editor is an "organization", with olive being one of its repositories, while InBetweenNames is a user, with gentooLTO being one of his repositories (tl;dr organizational versus personal).