On Thu, Jan 28, 2010 at 3:17 PM, Mike Linck
<mgl@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jan 28, 2010 at 1:03 PM, Michael Witten <mfwitten@xxxxxxxxx> wrote:
>> On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck
>> <mgl@xxxxxxxxxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html