On Wed, Jun 4, 2008 at 11:39 AM, Wincent Colaiuta <win@wincent.com> wrote:
quoted text
> 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]

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

I see where you're coming from, and I am learning to work more in this
way. Using git has made a big difference to how I develop. Not just as
a SCM, but also for improved work-flow. eg trying out things in code,
and storing failed attempts for later reference/retries/etc if it
doesn't work out.

My problem with your post is, even if you take this to the extreme
(topic branches for every fix that you want to make), there will still
be cases where while working on one fix (maybe disruptive to the main
branch), you uncover problems with master and start fixing it in your
topic branch.

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 :-)

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