Closed PaulMaynard closed 10 years ago
Oh! Git pull requests are between branches, so if you change your branch, it changes the pull request. This can be awfully confusing at first, but it ends up being incredibly handy, because it means if a mistake can be made you just update that one branch, rather than needing to do the pull request all over again. (Plus one can do things like squashing or splitting commits before the merge.)
This pull request is specifically for 7e079c3, yes?
Mostly that, yes, but i noticed splinterz pull seems to have reverted 84c1eae. c55ffa6 & de8c736 are covered by this pull, and the others are fixing some image sizes in the manual. And at the time, I was mostly talking about the older ones (1c2220f - 84c1eae), I thought you'd already merged them.
Oh sorry about that, I completely forgot to compare the changes you'd made to the branch I was working on. Thankfully we've got Paul to manage all the traffic! :)
"(Plus one can do things like squashing or splitting commits before the merge.)"
How do you do that?
"(Plus one can do things like squashing or splitting commits before the merge.)"
How do you do that?
git rebase -i
is the most common way to squash commits together. It's particularly useful if one has a workflow of "commit that does x" followed by a number of smaller "fixup x" commits. These can all be joined into one. For example c6d49e67e231d1f7fc0df2653f59dd3a9775a570 is merged commit that involved me cherry-picking out the commits I wanted, before rebasing them together into one. (Normally one wouldn't need the cherry-picking first, but I presume there were other commits mixed up in these.)
Splitting commits is a little more tricky. I do a git cherry-pick -n ...
to grab the commit in question, and then git add -p
to select which patches to put into each individual commit that I'm splitting from the original.
In both cases, we end up with new commits, with different commit-ids, so git won't necessarily know how these new commits came about. If the previous commits were in a public repo, then these commands may be changing history, which can screw up anyone who's written code based upon those commits. In most mature workflows I've seen the author of a patch or pull request will usually do the merging/splitting as required in their own branch, before sending the pull request. In the case of MWDF I've been doing a few of these as required, because they're not exactly a basic workflow feature, and it means that I can have contributors using practices they're used to while still maintaining a relatively clean commit history.
~ pjf
Also, git rebase
can be dangerous. Use with care. :)
So it looks like pjf/gold still needs the soap changes, fix for ash and the images changes, yeah? Once those are done I'll see about getting dffd updated for Meph so the 'official' version is more stable.
I re-added my soap and ash changes.
Wait, the soap/ash changes got lost? Pausing my critical-path paid work to investigate.
$ git bisect start
$ git bisect bad gold
$ git bisect good c6d49e6
$ git bisect run grep MAKE_SOAP_FROM_ASH_OIL_FUEL Dwarf\ Fortress/raw/objects/entity_default.txt
a7c837824540afa7a0336b484b633132de0ba53c is the first bad commit
commit a7c837824540afa7a0336b484b633132de0ba53c
Author: Josh <splintermind@gmail.com>
Date: Fri Mar 7 00:33:58 2014 +0100
update to masterwork 4i + fixes
- updated everything to masterwork 4i
- restored and fixed the dfhack.init for digging/razing
- updated the exe to the most recent version
- fixed the tree/plant/animal FF tags
- fixed the worldgen crash by ensuring that crows and sparrows are
always enabled in the masterwork vermin file
- updated gnomes to 0.72
Hmm, I probably shouldn't be doing this in a pull request, but I wonder why that commit reverted things. I know I did the 4i import (which preserved the soapmaking changes, even if they weren't in Meph's official release), so I'm guessing the a7c837824540afa7a0336b484b633132de0ba53c commit reverted these (possibly because it tried flipping files to exactly what was in 4i). Investigating.
Apologies for the delay, I'm working on this now. Since there are a few things that have already been fixed with other commits, I'm going to be cherry-picking across the remaining changes. :)
Okay, so the things we want are:
The log reactions and soap reactions should already be fixed in past commits.
With regards to the new minecart tile, do you know tilesets that's applicable for? (I haven't looked into this myself, and I've never used minecarts, but the fact that Masterwork has so many different tileset options makes lots of display problems difficult!)
Oh, and I'm not exactly sure what the changes are in spawn.lua
yet (I have to use cmdline-fu to see the effect of the combined commits, rather than github's nice view-changes feature).
Okay, I've cherry-picked the track changes over as 2e0b1c13f8e1462de1c57eeffa4a22222bc377a6 , and the manual fix-ups are in 6e94936.
The changes to spawn.lua
look like they're already in the repo, so I think I've got everything here and I can call it closed! Huzzah!
Since I've cherry-picked some changes over, you might want to re-adjust your gold branch to be the same as mine. You can do this with the instructions in the contributor's guide, which you should also feel free to update (it's a wiki, backed by git!).
Thank you so much for making these changes, and for your patience with me applying them. You rock! :)
Updated tanker carts and bladed and spiked carts and tracktraps to newer tile.
Also re-added the changes that got reverted in splinters v4i update