Re: [dev] git dmenu mirror with feature branches instead of separate patches

From: Dieter Plaetinck <dieter_AT_plaetinck.be>
Date: Sun, 21 Nov 2010 17:11:48 +0100

On Sun, 21 Nov 2010 16:30:55 +0100
v4hn <me_AT_v4hn.de> wrote:

> On Sun, Nov 21, 2010 at 04:14:26PM +0100, stanio_AT_cs.tu-berlin.de
> wrote:
> > Often, issues arise when applying multiple patches. The prposal
> > doesn't solve this, does it? For single features -- sure, it's
> > beneficial, but the work to keep stuff up to date with master
> > remains.
>
> Yes, there are problems with multiple patches. In my opinion
> we should spend some more time on making the optional patches as
> compatible as possible. - I did that with a couple of dwm-patches
> some time ago.

Right, there can still be merge conflicts when merging multiple
patches, but git (not sure about hg) is pretty smart about it, i.e. if
a block to be patched moved a bit downwards, it still
applies fine. So conflicts are less frequent, whereas normal patches
break completely as soon as a slight detail has changed.
Also, conflicts are easier to solve (or maybe i just don't have the
right tools to work with .rej files)

And, agreed with v4hn. Patches should be made "compatible" (but that's
not really related to the patchfiles vcs feature branches topic)

>
> > Set of branches based on multiple patches, representing different
> > dmenu flavours -- like surf-flavour (e.g. vertical and token match
> > and xyz ), dwm-flavour, someones-music-player-flavour -- might make
> > more sense... not sure.
>
> That's another option, but keeping track of applied patches on each
> branch will become a pile of work imho, so this again would result in
> making the patches compatible.

Actually that's a step I had in mind also. If we start off with normal
feature branches (i.e. master + 1 feature), you can get
"multiple-feature" branches by merging some feature branches together.
I could imagine in some cases features are so connected to each other it
makes more sense to maintain them together rather then trying to
separate them.
I would say we would make branches for single/multiple features based
on what makes most sense for each particular case.

Dieter
Received on Sun Nov 21 2010 - 17:11:48 CET

This archive was generated by hypermail 2.2.0 : Sun Nov 21 2010 - 17:24:01 CET