Re: Newbie grief

[Rich Pixley <rich.pixley@palm.com>]

On 5/1/12 14:12 , Junio C Hamano wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
>> Rich>  I want that if you and say, Sitaram commit conflicting changes to
>> Rich>  a shared branch, it's easy for me to recognize that the conflict
>> Rich>  exist and easy for me to resolve that conflict in my own
>> Rich>  repository.  I want the source code control system to keep track
>> Rich>  of those things, show them to me/us, and to track and show my
>> Rich>  resolution to you.  This stuff should all be automatic.  It
>> Rich>  shouldn't require explicit testing, manual pulling, nor explicit
>> Rich>  discussion between the three of us.  It shouldn't prohibit that
>> Rich>  either, but it shouldn't require it.
>>
>> You're asking a lot of an automated system.  I think you're trying to
>> get a system to replace the communication you should be doing as a
>> developer.
>
> While what Merlyn says is always right ;-), you could automate things by
> having your post-receive hook to notice that remotes/from-merlyn/master
> location was updated, attempt an automerge, and then report a failure.
>
> Not everybody wants such an automated system, so there is no such
> complexity in the vanilla setting, but the important thing is that whoever
> needs such a complexity could easily do so.

I think we have different definitions of "easily".  This is simple, 
first use sorts of stuff.  I've already invested weeks in trying to 
understand git enough to use it and I still don't have a process I like, 
much less do I know how to write a post-receive hook.  I'm sure I could, 
given enough time.  But frankly, I could switch to a different source 
code control system in less time.

Simple things should be simple.  They shouldn't require in-depth 
knowledge and customization of the tool.

In other systems, the automation is optional, but it's available.  If 
you want to vet each and every change as you take it, you can.  But you 
don't have to.

--rich