On Thu, Nov 10, 2011 at 12:38:16 -0800, Toshio Kuratomi <a.badger@xxxxxxxxx> wrote: > <nod> -- Although others have pointed out how to use git log and git > cherry-pick to achieve that... I find it faster to use git merge and just > remove the empty conflicts markers if I encounter this situation. Using git > log and then finding the commits that need to be pulled in seems to require > me to figure out which of the dozens of commits have been cherry-picked > already and which have not, keep track of their hashes, apply each of them, > and then try again. But I could be missing a simple cherry-pick subcommand > that would make this easier. I'm still getting used to git and do like to merge master into branches where they are all essentially in sync. But one thing I have been trying to get in the habit of is doing a git branch off of master to do complicated changes. I do local builds until it works and then merge the test branch in master and then later merge master into other branches. I think this can work better if master changes while you are working or if something works out to be a dead end and you want to mostly start over. And if something else comes up that you need to do to master while you are working you can do it pretty easily. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
