kde5.eclass
> case ${KDE_TEST} in
> false) ;;
> *)
> IUSE+=" test"
> DEPEND+=" test? ( dev-qt/qttest:5 )"
No >=${QT_MINIMAL} in this dep?
> else
> unpack ${A}
I think you can use `default`
> if ! in_iuse examples || ! use examples ; then
if ! use_if_iuse examples ; then
> if ! in_iuse test |
Diamond wrote:
>
> There's no git cp command.
> git mv is just git rm + git add.
I think there is a misunderstanding about how git works.
If you are used to e.g. svn (I suppose with CVS it is similar)
then it makes an important difference whether you use
"svn cp A B" or "/bin/cp A B", because sv
> On Fri, 19 Sep 2014, hasufell wrote:
> There is no reason to roll back commits or do merge commits for the
> keywords conflict use case. So I don't see what else needs
> discussion here, except the proposal from ulm.
About an optimised merge driver for ebuilds? Please don't see this as
a b
Ian Stakenvicius:
> Git on the other hand will update the entire
> tree and there's no way around that, right?
Yeah, people have to understand that we cannot map the cvs workflow 1:1
to git.
That's for a reason and that little inconvenience it causes is pretty
minor compared to the breakage CVS a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/14 11:10 AM, Ian Stakenvicius wrote:
>
> I don't think there's any valid debate on whether git is more
> efficient than cvs on fetching tree-wide updates :)
>
erm, that was worded wrong, let me try again: I don't think there's
any valid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/09/14 10:48 AM, Rich Freeman wrote:
> On Fri, Sep 19, 2014 at 10:25 AM, hasufell
> wrote:
>>
>> That is pretty easy and takes you ~20s for a keyword merge.
>> What's the problem?
>>
>
> Agree. Also, there was a comment that git pull is m
On Fri, Sep 19, 2014 at 10:25 AM, hasufell wrote:
>
> That is pretty easy and takes you ~20s for a keyword merge. What's the
> problem?
>
Agree. Also, there was a comment that git pull is much slower than
cvs. While it is true that git does refresh the whole tree all the
time, it is FAR more ef
Tobias Klausmann:
>>>
>>> If this should really turn out to be a problem, then we could also:
>>>
>>> 4) Replace git's default merge driver by our own one that is better
>>> suited for ebuilds. This can be done per repository via .git/config
>>> and .gitattributes.
>>>
>>
>> Certainly that would be
I've been working on unifying the PostgreSQL ebuilds for a while now.
Besides just being cleaner and taking a bit less time to compile, it
will inherently resolve a couple issues that are difficult to
workaround, such as cross compilation [1] and CFLAGS changes [2].
I'm including a list of affect
Hi!
On Fri, 19 Sep 2014, Tom Wijsman wrote:
> On Thu, 18 Sep 2014 19:39:08 +0200
> Tobias Klausmann wrote:
>
> > AIUI, we try to avoid merge conflicts, unless the merge is a
> > meaningful integration of divergent processes.
> >
> > However, one aspect of how ebuilds are written these days wil
On Thu, 18 Sep 2014 19:39:08 +0200
Tobias Klausmann wrote:
> AIUI, we try to avoid merge conflicts, unless the merge is a
> meaningful integration of divergent processes.
>
> However, one aspect of how ebuilds are written these days will
> cause a non-trivial amount of merge commits that are not
On 19 September 2014 06:51, Rich Freeman wrote:
>
> Git even allows the use of tools like meld to resolve conflicts,
> besides the usual fill-the-file-with-diffs-to-cleanup approach.
I'd personally discourage any kind of collision resolution in the merge
itself.
Mostly because I've been bitten
Hi!
On Thu, 18 Sep 2014, Rich Freeman wrote:
> On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller wrote:
> >> On Thu, 18 Sep 2014, Tobias Klausmann wrote:
> >
> >> However, one aspect of how ebuilds are written these days will
> >> cause a non-trivial amount of merge commits that are not actual
13 matches
Mail list logo
