X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20150318171037.26701.qmail@stuge.se>
Date: Wed, 18 Mar 2015 18:10:37 +0100
From: Peter Stuge <peter AT stuge DOT se>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] pcb alternatives
Mail-Followup-To: geda-user AT delorie DOT com
References: <5508413E DOT 4000405 AT ecosensory DOT com> <46050a0c DOT 619 DOT 14c2850d052 DOT Webtop DOT 45 AT optonline DOT net> <CAGYR9veihi_M+B0HXptGYQLMO8=B_KOLM2wmrRNkMLG_9MdQrA AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1503180357520 DOT 25799 AT igor2priv> <CAGYR9ve_n7VmZ8x-jCQK5eKHMNGp6an9o8EwYZnWQWFiCpGnXg AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1503180827170 DOT 25799 AT igor2priv> <CAC4O8c--CeEiKjxCKrs38XGjOyPS0Cy6scZ5HsAFgpi5xDpP_w AT mail DOT gmail DOT com> <201503181619 DOT t2IGJkZD012945 AT envy DOT delorie DOT com> <AC2776EE-AD74-4AC9-BCB1-9F40CC439B5D AT noqsi DOT com> <201503181646 DOT t2IGkZ0w013928 AT envy DOT delorie DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201503181646.t2IGkZ0w013928@envy.delorie.com>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

DJ Delorie wrote:
> > Well, of course, that's a matter of trying to do manually what git
> > does automatically. The commit messages are your changelog in git.
> 
> Designing a workflow around what your CMS requires is an example of
> the tail wagging the dog.

What if you think of it as a new breed of dog wagging its tail in a
new way, that lots of dogs like, and start mimicing?

I get it - you don't want to change how you work - but you need to
take responsibility for this being *your* issue, you can't blame it
on a tool. :)


> my example was one of "the project I work on has a workflow
> incompatible with git's desires" - *any* case where a project has a
> file that's commonly changed, and thus commonly conflicted, it
> going to suffer from git's workflow.

If a file is commonly conflicted there will be conflicts regardless
of what tools are used.

I understand prefering file locking over having to do post-mortem
conflict resolution, but personally I would rather avoid the conflict
from ever happening by communicating within the team. I realize that
this doesn't always work however, and I understand if some prefer a
tool to do it for them.


Kind regards

//Peter