Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process

[Tobias Klausmann]

Hi! 

On Thu, 18 Sep 2014, Rich Freeman wrote:
> On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller <ulm@g.o> 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