home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] another philosophical question about git -- avoiding merge problems

  • Subject: Re: [OCLUG-Tech] another philosophical question about git -- avoiding merge problems
  • From: "Brenda J. Butler" <bjb [ at ] sourcerer [ dot ] ca>
  • Date: Sat, 9 May 2015 00:58:17 -0400
On Wed, May 06, 2015 at 06:45:31AM -0400, Robert P. J. Day wrote:
> 
>   yet another process-oriented question about git ... not long ago, i
> was teaching a 1-day intro git course and, early on, one of the
> students mentioned that one problem they were having with their
> current VCS was too many people trying to check in changes and
> stepping on each others' toes and causing conflicts, and how did git
> solve that?
> 
>   i briefly mentioned git's merging ability and so on and so on but,
> in the end, i said that no tool was going to solve that; what she was
> talking about was a workflow issue that could only be solved by their
> developers *communicating* with each other; that is, *talking* about
> what parts of the code base they were working on so they didn't keep
> bumping into one another. and i emphasized that no level of
> sophistication of a VCS could replace developers talking to each
> other.
> 
>   i didn't think that was such a controversial position, but she did
> *not* take kindly to that. we were only about a half hour into the
> course, and she was already preparing to dislike git because of what
> she understood as its first major failing. i stuck to my guns, though,
> and by the end of the day, once she had a better understanding of git,
> she seemed a lot happier so, crisis averted.
> 
>   but, was i wrong? the position i took was that, regardless of the

I think you are right.  Git is a text diff-based tool (perhaps not
literally), and so the things that diff-utils does badly at (eg,
merging files with changes on the same lines) are the things that
git cannot solve in an automated fashion either.

>   i did suggest that there were alternatives. one i proposed was that
> all changes to the code had to relate to an existing ticket in a
> ticket system, and that developers should be required to (exclusively)
> check out the ticket to work on it.

Seems like a good approach, as long as a set of orthogonal tickets
can be written.  In the end, someone is going to have to do some
planning and/or the developers are going to have to communicate/
cooperate/collaborate.

bjb