On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
> Greg Stark wrote:
>> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <andres@anarazel.de> wrote:
>>> "git log --no-merges" hides the actual merge commits if that is what you
>>> want.
>>
>> Ooh! Life seems so much sweeter now!
>>
>> Given that we don't have to see them then I'm all for marking bug fix
>> patches which were applied to multiple branches as merges. That seems
>> like it would make it easier for tools like gitk or to show useful
>> information analogous to the cvs2pcl info.
>
> Right, if it adds additional metadata that lets the tools do their magic
> better, and it's still easy to filter out, I don't see a downside.
>
>> I'm not sure whether we should mark the old branches getting merges
>> down or the new branches getting merged up. I suspect I'm missing
>> something but I don't see any reason one is better than the other.
>
> If you go from older to newer, the automatic merge algorithms have a
> better chance of doing something smart since they can track previous
> changes. At least I think that's how it works.
>
> But I think for most of the changes it wouldn't make a huge difference,
> though - manual merging would be needed anyway.
In practice, isn't it more likely that you would develop the change on
the newest branch and then try to back-port it? However you do the
import, you're going to want to do subsequent things the same way.
...Robert
