Re: Questions about branches in git

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

On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten <mfwitten@gmail.com> wrote:
> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck
> <mgl@absolute-performance.com> wrote:
>> ...
>> It seems that after a topic or bug branch is merged back into its
>> parent, especially if it was fast forwarded, it becomes hard to
>> determine what changes were made in it, to resolve the problem that it
>> was created to address.
>> ...
>> I understand that there are mechanism kind of available to address
>> this problem.  If we (all developers in my company) remember always to
>> rebase -i before they merge their topic branches back in, then it
>> could be squashed making it easier to identify and cherry pick onto
>> other branches...
>
> For now, you should probably rely on graphical tools like gitk in
> order to visualize the various branches. There's also `git log

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.

> --graph'. You could also just keep your branches around for reference
> and use `git merge-base' as necessary.
>

Yeah, what concerns me is that there seems to be no point in keeping
your branches around "for reference" because even when you're looking
at them you can't tell what changes were made in them after they were
spawned, unless they haven't been merged into another branch yet.  So
it seems that a branch is only useful for merging once and unless the
branch was squashed in the process of mergin, good luck identifying
your change set for a particular topic.

I don't know if an uebercommit is necessary.  But it would help seem
like it would help if a branch knew about it's spawn point from its
parent, and if you could use that to get git log to only show you the
commits made to a branch after it was spawned.  And if there were
forms of operations like merge, or rebase that could act intelligently
based on that information like "merge this branch into that branch,
and by this branch I don't mean anything from this branch's parent
branch"  so that a fix that was developed on edge or master could be
safely merged into an old branch without importing every other change
on edge or master, and also the other way around.


I just looked at merge-base.  It doesn't seem to address the problem.
I grabbed an old topic branch from our repo which I knew was created
from master and at some point merged back into master via
fast-forward.  I checked it out, I called "git merge base topic-id
master", hoping that it would "output a commit which is reachable from
both A and B through the parent relationship."  Instead it seems to
have modified the topic branch by fast forwarding it to the include
all the changes up to the tip of master.  Clearly not what I'm looking
for.


Michael Linck