Re: Questions about branches in git

[Michael Witten <mfwitten@gmail.com>]

On Thu, Jan 28, 2010 at 3:17 PM, Mike Linck
<mgl@absolute-performance.com> wrote:
> 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 Jens Lehmann pointed out, use something like:

    git checkout master
    git pull --no-ff . topic

>> --graph'. You could also just keep your branches around for reference
>> and use `git merge-base' as necessary.
>>
> ...
> 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 would think that you'd only care about the contiguous commits
between merges anyway.

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

You incorrectly used `git merge' rather than `git merge-base'.

This is kind of off the top of my head. Try something like this:

    merged_commit_0=$(git merge-base master topic-id)
    merged_commit_1=$(git merge-base master ${merged_commit_0}^)

I think that should give you the range of commits between the last 2
merges (for at least simple cases). Then:

    git log $merged_commit_1^..$merged_commit_0

or

    gitk $merged_commit_1..$merged_commit_0

to see them.

You could, I suppose, keep looping until you find the oldest
merge-base that is still in the topic-id branch. To do so, the
following information may be of use:

    http://marc.info/?l=git&m=126457707700573&w=2

Anyway, it's probably best to use Nicolas Pitre's suggestion to use
tags to mark commits yourself, but the above might be useful if you
haven't.