Hi!
On Thu, 18 Sep 2014, Rich Freeman wrote:
On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller u...@gentoo.org 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
On 19 September 2014 06:51, Rich Freeman ri...@gentoo.org 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
On Thu, 18 Sep 2014 19:39:08 +0200
Tobias Klausmann klaus...@gentoo.org 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
Hi!
On Fri, 19 Sep 2014, Tom Wijsman wrote:
On Thu, 18 Sep 2014 19:39:08 +0200
Tobias Klausmann klaus...@gentoo.org 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
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
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 even more helpful!
On Fri, Sep 19, 2014 at 10:25 AM, hasufell hasuf...@gentoo.org 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,
-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 hasuf...@gentoo.org
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
-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
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
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 blocker
Diamond diam...@hi-net.ru 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,
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 || ! use test
From: Alexander Berntsen alexan...@plaimi.net
Signed-off-by: Alexander Berntsen berna...@gentoo.org
---
Use 'is' instead of '==', as recommended by Zac.
man/emerge.1| 3 ++-
pym/_emerge/depgraph.py | 7 +--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git
This fixes the unmerge-backup and downgrade-backup features to be
compatible with the new setup.py quickpkg install location, while
preserving compatibility for running from a source tree (for unit tests
or development purposes). If not running from a source tree, then the
PATH variable is used to
On Fri, 19 Sep 2014 16:35:30 -0700
Zac Medico zmed...@gentoo.org wrote:
This fixes the unmerge-backup and downgrade-backup features to be
compatible with the new setup.py quickpkg install location, while
preserving compatibility for running from a source tree (for unit
tests or development
16 matches
Mail list logo
