Re: Questions about branches in git

[Mike Linck <mgl@absolute-performance.com>]

On Thu, Jan 28, 2010 at 2:29 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 28.01.2010 22:17, schrieb Mike Linck:
>> Well, even gitk can't show me the information I'm looking for if the
>> parent branch ended up fast-forwarding to include the changes made in
>> the topic branch.  As far as I can tell there is *no way* to tell what
>> changes were made in a particular branch after a fast-forward has
>> taken place, which seems to make it hard to organize fixes for
>> specific topics/bugs/tickets.
>
> You could disable fast forward merges using the --no-ff option. Then
> git will always create a merge commit even if it could have done a
> fast forward. This can be enabled permanently for a branch with
> 'git config branch.master.mergeoptions  "--no-ff"'. We use that at my
> dayjob to preserve the branches after merging.
>

OK, so what I'm getting is that if a developer forgot to disable
fast-forward when they created a topic branch, and if the parent
branch has been fast forwarded to include it, then you might as well
just throw away the topic branch, is that correct?

Could anyone point me to a good book that actually describes the style
of code management that git was intended to support?  Because I'm
finding this a bit baffling, to be honest.  I thought it was intended
to make the developers' side of code management easier to do, but it
seems to me that they have to think a lot harder about what they're
trying to accomplish, at least in this sort of case.  I'm not trying
to be rude, but I just feel that if I want to keep working with this
tool, I have to rethink how the code is organized in a pretty
fundamental way and I'd like to get as comprehensive of a guide as
possible from someone who has adopted their tactics to it.

Thanks

Michael Linck