Bruno Wolff III <br...@wolff.to> wrote:
On Thu, Nov 10, 2011 at 12:38:16 -0800, Toshio Kuratomi <a.bad...@gmail.com>
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I would recommend rebasing branches against master up until they are pushed, if
required to be shared. Doing so retains a linear history on the branch and can
mean the branch commits can end up being fast forwarded onto master when the
feature is complete.
My 2p
Cheers
Phantomjinx
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
