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 actually > >> useful in that sense. > > > > Git can do merge conflict markers just like cvs. Also, in practice I > don't tend to run into merge conflicts with cvs - I always do a > directory update before making changes. With git I'd probably not do > a pull if I were working on an obscure pacakge, but if I were doing a > security keywording I'd certainly do a pull before touching anything > since the likelihood of a conflict is much higher.
The problem isn't the conflict markers. The problem is that with git, by the time I have a conflict, I also have a local commit that I have to roll back or turn into a merge, which means extra work. > Git even allows the use of tools like meld to resolve conflicts, > besides the usual fill-the-file-with-diffs-to-cleanup approach. > > > > > 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! Still, all of these scenarios cause merge commits, which some people seem to be rather allergic to (and I do agree that nothing of use is actually merged, since two stabilizations/keywordings are usually orthogonal). Regards, Tobias
