Re: Questions about branches in git

From: Mike Linck <mgl@absolute-performance.com>
Date: Jan 28, 2010, 21:38 UTC
Message-ID: <69b754db1001281338l58eb4b84t5a5725de294b6cc5@mail.gmail.com>
In-Reply-To: <4B6201BC.9030800@web.de>

On Thu, Jan 28, 2010 at 2:29 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:

Show 14 quoted lines

> 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