rendering of transparent walls is broken

[Rachael]

Another trick when Graf force pushes, as long as you aren't trying to maintain a fork or feature branch, is you can simply use the following command:

Code: Select all

git fetch --all
git checkout -B master origin/master

Please keep in mind this will destroy *EVERYTHING* you have on your local master, so be sure that you want an exact copy of Github's master before you do this and save any work you have into another branch before doing so. If you have anything you want to save, you'll have to rebase or cherry-pick it.

The best part about this is, you can put it in a batch file and you don't have to fudge around with old commits, it's automatic and quick.

[dpJudas]

I'll be a little blunt here and just say there's a reason why GitHub has a "protected branch" feature that should normally be enabled for upstream branches like GZDoom's master branch.

GZDoom has 142 official forks and it is unreasonable to tell those people to execute dangerous git commands that could do all kinds of havoc on their own repositories if they don't have the black belt in git history manipulation.

[Graf Zahl]

The best protection is useless, though, if that branch contains thoroughly broken content. There was one commit in there that was utterly unsalvageable and had to be removed entirely. Sometimes it just happens and you notice too late.

This couldn't be fixed by applying a corrected merge.

[Rachael]

Actually, it can be, by doing a "dead merge" - where a second head is transferred in but no content is actually changed.

I don't know exactly how to do it "easily" but I know I managed to merge in the entire history of gzdoom-last-svn without changing anything at one point.

It's one thing to keep a clean commit history, and that I can understand, but it's also another thing to a) following one's own rules about doing such work in a branch, and b) keep the master branch upstream compatible for contributors and collaborators.

[ketmar]

@Graf: that is where "git revert" is useful: just revert everything done wrong, and commit The Right Thing. this way no history is broken. so it *can* be fixed without history rewriting.

[Rachael]

Or do it in a branch, so that no one's work is destroyed when you do a force-push.

Mainly, you always want to avoid polluting a popular upstream branch that a lot of people frequently pull from, and if your concern is about keeping commit history clean (since _mental_ often cites the need to bisect work and a clean history helps with that), it's a good compromise and allows you to do both.

[Nash]

I'm a bit hesitant to post this, and please don't get me wrong, but I'm going to have to agree with doomed_stranger and Rachael/dpJudas ... as a maintainer of a fork too (with several local changes, in fact), sometimes these forced nukes cause a lot of problems. I have been intentionally holding back on pulling commits now because I'm afraid of the ensuing mess ups.

I personally feel "git revert" is better than nuking master...

[Graf Zahl]

@Graf: that is where "git revert" is useful: just revert everything done wrong, and commit The Right Thing. this way no history is broken. so it *can* be fixed without history rewriting.

Normally yes, but in this particular case that wasn't possible because I had to rebuild some stuff with other, later commits in mind. I had to go back to an earlier clean commit and put the working stuff back in and leave the bad stuff out. Once that was done it was impossible to merge. I tried but it didn't work.

[ketmar]

i'm afraid that i don't understand you. reverting commit is EXACTLY the same thing as removing it -- only without history rewriting. if it is possible to nuke commit, it is possible to revert it. it just cannot work in any other way.

[Graf Zahl]

No, not correct. You cannot revert a commit when a following commit changes that commit's changes.

[Rachael]

Graf, I wouldn't be too sure about that. Revert does exactly the same thing as cherry-pick, except in reverse.

Nevertheless, it's irrelevant, if you simply switch to a branch.

[Graf Zahl]

Cherry picking - just like reverting - does not work and throws a conflict if it cannot be merged cleanly. And if it can be merged manually depend on the extent of the changes. There are countless situations where I couldn't cherry pick some older changes and had to keep in those annoyingly long branches.

[Nash]

My usual workflow for git revert, when there are multiple commits, is I execute revert in the reverse order, 1 commit at a time, until I reach the point where I can clean something up. The commit history and files would still be accessible in case I'd need to copy/paste something.

[Rachael]

All that is why I am suggesting, repeatedly, to do this in a branch.

[ketmar]

@Graf: in both cases (reverting and nuking) you have to fix later commits. with reverting, you have to do some work with "selective revertion" (in backwards order), with nuking, you have to do some work to make later commits apply cleanly. in both cases it is almost the same thing, and roughly the same amout of work. only clean reverting retains clean, unbroken history. you can apply patches selectively down to line (well, several lines, but slightly smaller than the whole hunk) granularity, and revert is just an ordinary patch.