Re: Branch dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



also sprach Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> [2011.08.02.1506 +0200]:
> while I appreciate, that you dig this topic up. I think you are trying
> to solve the wrong problem first. My main problem with the TopGit
> approach is, that you can't freely change the dependencies of a topic.
> This may be not the most common case in distro development. But in my
> eyes more problematic than maintaining the meta data.

Hello Bert, thank you for taking the time to respond!

Could you please try to illuminate me a bit on a use-case of
changing dependencies? I am aware that TopGit has had a problem with
changing dependencies due to renamed branches, and I think I have
a solution to that (encode the dependent ref, not the branch head),
but I cannot come up with a use case for freely changing
dependencies just like that.

> For my first mentioned problem, I think a new 'system' needs to be
> 'rebase' based, not merge based like TopGit.

The problem with rebasing is that you cannot publish the branches.

However, maybe I am simply not seeing the light here. Do you have
some further ideas about what this would be like? Please keep in
mind that what I seek is not just a way to bring feature branches
up-to-date with upstream, but also to have those branches be shared
among developers.

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"gott ist tot! und wir haben ihn getötet."
                                                 - friedrich nietzsche
 
spamtraps: madduck.bogus@xxxxxxxxxxx

Attachment: digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]