Re: Re: Questions about branches in git

From: Heiko Voigt <hvoigt@hvoigt.net>
Date: Jan 28, 2010, 23:07 UTC
Message-ID: <20100128230726.GC39683@book.hvoigt.net>
In-Reply-To: <69b754db1001281338l58eb4b84t5a5725de294b6cc5@mail.gmail.com>

On Thu, Jan 28, 2010 at 02:38:14PM -0700, Mike Linck wrote:

Show 20 quoted lines

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

If you want to enforce this you can use an update hook on the receivers side and check that a branch update can only be made to real merge commits.

The practise we use at $dayjob is that we prepackage git installations containing default values in /etc/gitconfig so its not easily forgotten.

Show 10 quoted lines

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

As stated in a later message there is no such thing as the design goal for git. Its designed by practise which has made it so flexible that you can design you own.

cheers Heiko