On Thu, Jan 28, 2010 at 3:18 PM, Michael Witten <mfwitten@xxxxxxxxx> wrote:
> 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.
>
Well, I'll be using tags more in the future and I'll look through some
more documentation about recommended workflows and see if I can work
out something that will do what we need to do.
Your example will work on non-FF branches if you make the second
merge-base use master~1 (else it just gives you the same commit sha
twice)
The tough thing to identify is the change sets that got fast-forwarded
in though. I guess I'll just go ahead and erase those branches since
they won't do any of us any good anyway and I'll read up on the work
flow, and try to avoid having the same mistakes recur.
thanks again,
mike
--
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