Re: User's mailing list? And multiple cherry pick

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2008.06.04 12:02:13 +0200, David wrote:
> On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta <win@xxxxxxxxxxx> wrote:
> > El 4/6/2008, a las 10:30, David escribió:
> >
> >> Thanks :-) This still isn't what I had in mind (see my earlier post
> >> with examples), but I realise now, thanks to your post, that I can
> >> probably do it like this:
> 
> [snip]
> 
> >
> > Sounds like it would definitely work but it also sounds like a lot of
> > repetitive "busy work"[1] which could be avoided by using finer-grained
> > topic branches in the first place.
> >
> 
> It isn't always easy to fix the problems in master (that you're seeing
> in topic) by changing back to master and making another topic. Maybe
> you can only (easily) find & detect the problems in master because of
> other changes in topic (eg: WIP unit tests) that you aren't ready to
> merge yet.
> 
> So you would probably have to jump back and forth between your topic,
> and your new 'fix problems in master' branch a lot to track down the
> issues and get the fixes into master. This sounds like a lot more
> 'busy work' than simply cherry-picking (multiple) those fixes out of
> your topic branch into master, and then rebasing your topic branch :-)

The unit tests example is a pretty good use-case for rebase --onto.
Simply start your new topic on top of the WIP topic, you don't always
have to branch from master. Then you have the all the code around. Fix
the bug, and finally rebase your new topic onto master.

git checkout -b bug_fix_branch wip_branch
# work work work, commit commit commit
git rebase --onto master wip_branch bug_fix_branch

Eventually, you'll have to add stuff to your wip_branch while doing the
bug_fix, but that's relatively straight forward.

git checkout wip_branch
# work work work, commit commit commit
git rebase wip_branch bug_fix_branch

And then you can continue to work on the bug fix branch and at some
point end up at the rebase --onto from above.

Of course for stronger dependencies between wip_branch and
bug_fix_branch, that's not possible, but then you most likely wouldn't
want to cherry-pick the bug fix stuff into master anyway.

Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux