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.

> 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.

-Toshio

Attachment: pgpVWkNqJ9St2.pgp
Description: PGP signature

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to