On Thu, 2011-11-10 at 12:38 -0800, Toshio Kuratomi wrote: > On Thu, Nov 10, 2011 at 11:59:50AM -0800, Adam Williamson wrote: > > On Thu, 2011-11-10 at 08:55 -0800, Toshio Kuratomi wrote: > > > On Thu, Nov 10, 2011 at 09:02:45AM -0500, Simo Sorce wrote: > > > > On Thu, 2011-11-10 at 13:27 +0100, Michael J Gruber wrote: > > > > > I'm sorry but the reason is that people don't know git workflows. > > > > > > > > I guess it depends on what is the maintainer preferred workflow. > > > > > > > > I personally hate git merge, especially for stuff so simple as fedora > > > > trees. It gives no advantages I can see to the way I work and causes > > > > quite a lot of bad side-issues. > > > > > > > > [..] > > > > > > > I've found git cherry-pick hard to use compared to git merge -- but then > > > again, I'm using cherry-pick to actually cherry-pick; not keep two branches > > > in sync. > > > > > > So if my usual workflow is commit to master, test, commit, test, then > > > make fX equivalent to master and build there, what is the cherry-pick way to > > > do that simple task? > > > > > > git merge way would be: > > > > > > $ git checkout f16 > > > $ git merge master > > > > > > which seems very simple and very suited for this particular workflow. > > > > As I've understood the thread so far that's fine - so long as you > > actually want master and f16 to be the same, of course. I'm not sure > > what you're supposed to do when master has a later version of the > > package than f16, but you want to introduce some other change to both > > branches, for e.g. > > > Yeah -- That's where I would start to use cherry-pick. I was jsut asking > since it seemed that Simo was saying that he thought cherry-pick was > a better idea even in the case I outlined above. So I was curoius if I was > missing something. No, if the branches are identical then by all means keep them aligned. But once they diverge, do not try anymore, at that point merges will just mess up the history with no gain whatsoever. > > My problem came in the case where someone has already *not* done this - > > they've updated f16 separately from, and more than, master, and I wanted > > to get them back in sync. > > > <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. A merge in this case only risk to bring changes you do not want in one of the trees. Although cherry-pick is more tedious, you already have to do that job anyway to make sure you are not bringing in stuff you do not want to, so you can as well just do it. Of course the best course of action is to just apply the same commit to all branches it applies to when you create it and not wait months before doing that, but that's the ideal and reality often diverge. Another way you could use id to create a 'feature' branch and use rebase -i to play with commits , but that could end up being more complex than just chery picking for some issues. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
