davewx7 / citadel

A turn based strategy game based on the Anura engine
Other
99 stars 25 forks source link

Adjustment of "Quantum in..." avatar #185

Closed pacnutek closed 6 years ago

pacnutek commented 6 years ago

Changes done in the dev_tools tool

ghost commented 6 years ago

Your master branch is somewhat de-synchronized from upstream. Maybe I can help you to fix that.

Are you using Microsoft? That be the case, could you please execute this commands on your Git shell and share your output?

$ git config --list | grep remote | grep url

That is a read-only command. You can execute it as many times as you want or need.

I expect it to output something like:

remote.origin.url=https://github.com/pacnutek/citadel

It could include your password. If so, please remove it and share the rest.

pacnutek commented 6 years ago

remote.origin.url=https://github.com/pacnutek/citadel.git remote.upstream.url=https://github.com/davewx7/citadel.git

I would like some help with git, thank you. I cant get my mind on it. Tried with the rebasing but that created a bigger mess than this upstream mergers.

ghost commented 6 years ago

Git is easy. It is just stiff. GitHub can help you a lot. Find the network map of Dave at https://github.com/davewx7/citadel/network. Most the times when trouble like this happens it is very helpful to be able to see the graph of revs.

The visual is crucial so to know where you are, where are others, and most importantly where is the project (and where you want it to be later in the day), which normally imposes a one way restriction on where other people think now the project is and on where people think the project will be in the near future, yet no one can ever tell for 100% sure.

I will guide you through several steps, and it could work. Depending on shit and stuff, it could not match your output at all. For sure it is not going to match exactly, but hopefully it might solve the problem.


In case of disaster, prevent data loss by not taking any chance of the possibility. Save your current master branch with a disposable name:

$ git checkout -b master-201802011027
Created branch 'master-201802011027'.
$ _

Hell, back it up in the cloud, for it is currently gratis.

$ git push origin master-201802011027
Pushed branch 'master-201802011027' to 'origin'.
$ _

You can play risky now with master. So get back to master.

$ git checkout master
At 'master'.
$ _

At this point I think simply rebasing on upstream and force pushing to origin will do. Yet I can not guarantee. Run this:

$ git fetch upstream
[...]
$ _

Then this:

$ git rebase upstream/master
First, rewinding head to replay your work on top of it...
Applying: Adjustment of "Quantum in..." avatar
$ _

If the snippet seemed to fail on your system, or if by any chance you could not get to this point, then share your output for git --version.

Chances are the snippet seemed to work, and if that was the case, it would be probably then the time for a force push on origin, that you can do because origin for you is... you. Yourself at the cloud. Before the next step you must always be sure of what is origin, by any means necessary, including using git config --list to read the configuration of your local clone.

$ git push --force origin master
[...]
$ _

Hopefully after this your master will be a lot cleaner from merge commits. Those merge commits have a reason to exist, and a purpose, and anyone allowed to do so could perfectly have merged earlier at the day, if there had been any rush to have them merged.

All these, if everything ran OK, do not make it a clean master. But I think it'll make a cleaner master. Your change will get merged and soon you will be able again to merge from upstream with the possibility to fast forward.


You must never force push on a repository that is being used by more than one people. Shit happens and anyone can unfortunately break things for people just by accidentally having origin set to a central repository where you might have write privileges.

pacnutek commented 6 years ago

So in short you say to do rebase to upstream instead of merge to upstream. This should eliminate the merge commits and thus make the history more clean.

Additionally if I make myself a development branch on my master I should also do rebasing to my master after I did the upstream rebasing. Is that correct?

pacnutek commented 6 years ago

Also I think I could squash those merge commits. Dont know if it is recommended.

ghost commented 6 years ago

So in short you say to do rebase to upstream instead of merge to upstream. This should eliminate the merge commits and thus make the history more clean.

By merging upstream the merge commits shall remain there. I don't think it will remove them.

The merge commits can be removed by rebasing, either automatically by rebasing on top of upstream/master as I am seeing Git 2 does, or manually by rebasing interactively (-i flag of git rebase) and removing them from the rebasing plan in the case they appeared in it (at least in Git 2 it seems to me they are never appearing, I'm guessing that becase they are clean merges, but I think, and I'm probably wrong, that in Git 1 they always appeared).

The merge commits can be removed by resetting, such as git reset --hard HEAD~6 when having master in 77ef8dbfc755eae, and from then rebasing on top of upstream/master, or merging it, as preferred (if it made really a lot of sense to maintain fd42665939e3b on its current base at c0ad4f9179fb5, IDK, to keep it near the rest of the Quantum in oculis deorum definition, for instance; but I don't think there is the need). This should remove the previous merge commits, and if you merged after resetting a new single (empty) merge commit would be there. In any of either cases the history is simpler.

Additionally if I make myself a development branch on my master I should also do rebasing to my master after I did the upstream rebasing. Is that correct?

I don't know if you mean a local development branch you already have locally but not shared at GitHub, or if you mean a branch you plan to have, so I can't answer.

Also I think I could squash those merge commits. Dont know if it is recommended.

I guess there is a way to squash clean merge commits, but I don't know how.

pacnutek commented 6 years ago

Made a new commit on my master and it was added to this pull request - didnt see that happening. Anyway the new commit can be pulled if it where up to me. Please review before adding to the code base.

New changes done via the ingame dev tools.

pacnutek commented 6 years ago

You mean the value after the "text":, the "ERROR..." string? This is an inside joke ;) It is an error message ppl where getting after one of my changes was put into the game and it made the game crash. I copied the text from the bug report and pasted it here as a fail text of the encounter - if you fail you get this text that looks like an AA error message. I only replaced the persons user name for my nickname in the path in the string.

ghost commented 6 years ago

Oh. You caught me. I thought you were slipping to the commit some kind of weird error affecting the campaign development tool.

I guess the weird message will be rendered as Mellow italic? If you feel like preferring a monospace style font for it, or even a userland API to the SDL dialog boxes, maybe we have that at reach.

http://youtu.be/1-_-QxerYno

🤷‍♂️