Re: Questions about branches in git

[Eugene Sajine <euguess@gmail.com>]

I agree with Nicolas here - i was also thinking about using
lightweight tags in this case. If you really, really need to port
changes to multiple branches, tags would show you exactly which
commits you should work with.

git log tag1(branched)..tag2(brnach_ready)

In addition to that i shold say that most of the time branches are
supposed to be created from the latest stable master, i.e. released
code. Each release should be tagged. So, in this case you don't need
to have to have the first tag, as you branching from a tagged commit.
As soon as you have first point, second tag may be not necessary until
you can operate with the last commit. As soon as it is not possible -
you can create lightweight tag.

On Thu, Jan 28, 2010 at 5:04 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> On Thu, 28 Jan 2010, Mike Linck wrote:
>
> > 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 should consider using tags in conjunction with your bugs/tickets
> system.  The fork point for a bug fix may be tagged, as well as the last
> commit representing the bugfix completion (not the merge point though).
> This way you can always retrieve the exact set of commits forming up
> that bugfix, regardless if it was merged back into the main branch with
> a fast forward or not.
>
>
> Nicolas
> --
> 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